Announcements

Help us improve the Power & Sensing Selection Guide. Share feedback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
jbakerLS
Level 1
Level 1
5 questions asked 5 replies posted 5 sign-ins

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

0 Likes
3 Replies
Aditi_B
Moderator
Moderator
Moderator
500 replies posted 5 questions asked 250 replies posted

Hi,

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

Thanks

Aditi

0 Likes

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).

0 Likes
lock attach
Attachments are accessible only for community members.

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

0 Likes