Cypress: FPGA: gpio test looks like not valid

[yarbcy]

Description of defect

Cypress: FPGA: gpio test looks like not valid.

In file TESTS/mbed_hal_fpga_ci_test_shield/gpio/main.cpp line 165:

`
// Initialize GPIO pin as an input, pull-up mode.

memset(&gpio, 0, sizeof gpio);

gpio_init_inout(&gpio, pin, PIN_INPUT, PullUp, 0);

TEST_ASSERT_NOT_EQUAL(0, gpio_is_connected(&gpio));

tester.gpio_write(MbedTester::LogicalPinGPIO0, 0, false);

wait_us(HI_Z_READ_DELAY_US);

TEST_ASSERT_EQUAL_INT(1, gpio_read(&gpio)); // hi-Z, pulled up

gpio_free(&gpio);`

PSoC6 set 0, tester(FPGA) set 0. But expect 1. Test FAILED. It looks like it doesn't make sense.
This test PASSED if set PSOC6 1, tester(FPGA) set 0.

Target(s) affected by this defect ?

Tested on CY8CKIT_062_WIFI_BT

Toolchain(s) (name and version) displaying this defect ?

Tested on GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

Latest

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

N/A

How is this defect reproduced ?

Always

[yarbcy]

@0xc0170

[0xc0170]

@yarbcy What is not valid in the code snippet above?

cc @mprse

[yarbcy]

@yarbcy What is not valid in the code snippet above?

cc @mprse

PSoC6 set 0, tester(FPGA) set 0. But expect 1

[0xc0170]

Isn't it that you write 0 (fpga side), but because of pull up you expect 1 on the actual pin?

This comment explains it : // hi-Z, pulled up

[yarbcy]

Isn't it that you write 0 (fpga side), but because of pull up you expect 1 on the actual pin?

This comment explains it : // hi-Z, pulled up

Yes. But PSoC6 also set initial state 0.

[yarbcy]

@0xc0170 @mprse
All the rest GPIO test are passed. Except this one.

[0xc0170]

gpio api supports value even for input, it writes to gpio as it claims "for future use if you switch to output". Although as soon as you change the direction, you write a new value so I dont understand the use case for that condition there).
My expectation, once you set pin to input, it goes into Hi-Z state (no matter what you write as a value, it shall be ignored. As soon as you change the direction, the value is preserved and output equals to the value we wrote earlier), and that is what the test also expects. How does it work for failing target? What happens if you set direction to input to the pin itself?

I cant find it in the history why it was there, will need someone else to look at this closer.

[yarbcy]

From my point of view:

1. PSoC6 set PullUp drive mode (Input)
2. Set gpio_write(0) (I see it on logical analyzer)
3. Set tester (FPGA) 0
4. gpio_read() return 0. But expect 1.

[mprse]

Test scenario:

1. Set Mbed GPIO to pulled-up input. Provided value, in this case, is irrelevant.
2. Set the corresponding pin on the FPGA side to Hi-Z (something like no connection between GPIOs).
3. Read the Mbed GPIO.
4. Expect logic 1 since the pin is pulled up.

Maybe pull mode does not work on the cypress board?

[yarbcy]

@mprse Cypress support pull mode.

This case is passed if replace gpio_init_inout() -> gpio_init_in_ex()

Could you please help me understand why?

[mprse]

void gpio_init_inout(gpio_t *gpio, PinName pin, PinDirection direction, PinMode mode, int value)
{
    if (direction == PIN_INPUT) {
        _gpio_init_in(gpio, pin, mode);
        if (pin != NC) {
            gpio_write(gpio, value);    // we prepare the value in case it is switched later
        }
    } else {
        _gpio_init_out(gpio, pin, mode, value);
    }
}

void gpio_init_in_ex(gpio_t *gpio, PinName pin, PinMode mode)
{
    _gpio_init_in(gpio, pin, mode);
}

gpio_init_inout() calls _gpio_init_in() and gpio_write().
gpio_init_in_ex() calls only _gpio_init_in().

This call to gpio_write() is suspicious. Probably this is done to set the value for the future if the port direction is changed (according to #11835 (comment)).
Maybe the gpio_write() changes the port direction?

[yarbcy]

Maybe the gpio_write() changes the port direction?

Looks like no.

But why we have initial state for input pin it should be done for output pin. Right?

[0xc0170]

That is what I dont understand. 😞

anyway, what happens on the pin if you set it to output (it should be floating, no value set?). Is this documented in the reference manual for that MCU ? What is expected behavior for input pin?

In case the pin has different behavior than we expect (@mprse I havent found the behavior defined in the gpio_api header file for this inout function), you can always check in HAL (if pin is output, and something asks to write to the pin, ignore it and keep it floating).

[kjbracey]

Looking in apply_config, called from gpio_dir for PSOC6, I see

if (obj->drive_mode == PullUp) {
    gpio_write(obj, 1);
...

Suggesting that the gpio_write control is used to set the pull - presumably it's acting as a "weak drive".

That test (and the init_inout) seems to be assuming that the gpio_write has no effect until the direction is switched.

Seems like achieving that would need a more advanced gpio_write implementation - which is unfortunate as we normally like it to be a nice small inline register write.

[mprse]

static inline void gpio_write(gpio_t *obj, int value)
{
    if (obj->direction == CYHAL_GPIO_DIR_OUTPUT) {    <--- set only if output
        MBED_ASSERT(obj->pin != CYHAL_NC_PIN_VALUE);
        cyhal_gpio_write(obj->pin, value != 0);
    }
}

static inline void gpio_set_pull(gpio_t *obj, int value)  <--- new function for setting pull mode
{
    MBED_ASSERT(obj->pin != CYHAL_NC_PIN_VALUE);
    cyhal_gpio_write(obj->pin, value != 0);
}

void apply_config(gpio_t *obj)
{
    MBED_ASSERT(obj->pin != CYHAL_NC_PIN_VALUE);

    cy_rslt_t rslt;
    if (CY_RSLT_SUCCESS != (rslt = cyhal_gpio_configure(obj->pin, obj->direction, obj->drive_mode))) {
        MBED_ERROR(MBED_MAKE_ERROR(MBED_MODULE_DRIVER_GPIO, CY_RSLT_GET_CODE(rslt)), "cyhal_gpio_configure failed");
    }

    if (obj->drive_mode == PullUp) {
        gpio_set_pull(obj, 1);  <--- use new function for pull mode
    } else if (obj->drive_mode == PullDown) {
        gpio_set_pull(obj, 0);  <--- use new function for pull mode
    }
}

Maybe something like this?