ISM43903 wiced_init causes GPIO control problems

[jbakerLS]

I am working on a project built on the ISM43903 using WICED STUDIO version 6.6 . This project was an updated project ported from ISM43362 using WICED STUDIO version 3.5.2.

I have a Green LED on pin 23 aka GPIO 0. Below is the code for platform initialization.

Setup/Initialization code:

led1_init_result = platform_gpio_init( &platform_gpio_pins[WICED_LED1], OUTPUT_PUSH_PULL );

Where WICED_LED1 is defined by 

#define WICED_LED1 ( WICED_GPIO_1 )

Where WICED_GPIO_1 appears in the patform_gpio_pins[] array here:

[WICED_GPIO_1 ] = { PIN_GPIO_0 }, //GPIO0/I2C1_SD 23

In the application code, I can set the Green led high prior to wiced_init() is called just fine. After wiced_init is called, control to the GPIO is ignored.

After some investigation, the function index appears to be changing from 0 (PIN_FUNCTION_TYPE_UNKNOWN) to 16 (PIN_FUNCTION_TYPE_GPIO) following wiced_init() calls.

By modifying the platform SDK code, I've managed to work around this by modifying platform_gpio_output_high calls:

 /* Lookup the pin internal configuration and current function index value */
gpio_result = platform_pinmux_get_function_config(gpio->pin, &pin_conf, &pin_function_index);

then adding a check for the function type problem, then deinit + reinit as below:

if ((pin_conf->pin_pad_name == PIN_GPIO_0) && ((uint32_t)pin_conf->pin_function_selection[pin_function_index].pin_function_type == PIN_FUNCTION_TYPE_UNKNOWN))

{
gpio_result = platform_gpio_deinit( &platform_gpio_pins_[0] );
gpio_result = platform_gpio_init( &platform_gpio_pins_[0], OUTPUT_PUSH_PULL );

}

Where platform_gpio_pins_[0] is crudly built as 

const platform_gpio_t platform_gpio_pins_[] =
{
[0] = { PIN_GPIO_0 },
};

I have searched my project for references to WICED_GPIO_1 and GPIO_0. The results are

• WICED_USB_HOST_OVERCURRENT within BCM4390x subfolder. This application doesn't enable USB.
• I2C 1 SDA - This project uses I2C0, not I2C1.
• #define PLATFORM_FACTORY_RESET_LED_GPIO ( WICED_LED1 )

Is there any other way to determine what might be repurposing or uninitializing this GPIO?

I'd prefer to find the root cause rather than this "hack" of the platform_gpio module.

I haven't found documentation to describe the GPIO control registers for this,  but in debugging the code I've determined that a control register must be set in order to configure the function index of a GPIO.

any thoughts, or even documentation to help identify GPIO Control registers and how it's handled would be helpful. 

Thanks,

Jason

[Aditi_B]

Hi,

Will it be possible to share the code example with us?

Thanks

Aditi

[jbakerLS]

Unfortunately I can't provide the source code I'm working with.

I'll try to see if I can replicate this issue with an example, modified to use gpio 0 in the same manner as what my project uses it for (an output to turn on an LED).

[jbakerLS]

Ok, so I've gotten some time to attempt this on snip.scan example using my platform files. (It failed in the same way with snip.scan example)

I then took a fresh copy of the SDK's platform file and edited the platform files to call it ISM43903_R48_L54_SCAN. Edited specifically to run the snip.scan example on it without other I/O being initialized (except UART).

I slightly modified the scan.c code to Set the Green LED (Pin 23) to high right before wiced_init is called, as well as within the scan loop.

I'm only able to observe the green LED turning on again following wiced_init by adding the "hack" I mentioned in the opening post of checking the pin function and re-initializing the output whenever I attempted to set the green LED.

With this "hack" in place, prior to a scan being started, the LED is set green as expected, but shortly after it is turned off.

I didn't provide the code that checked and re-initialized the LED. But you should be able to observe that the pin function index has changed between configuring it and following wiced_init.

Jason