Odd issue where lines are intermittently not going low when calling nrf_gpio_pin_clear

[mbp83]

Let me preface by saying I'm pretty new to working at this low of a level.  I'm running a pretty simple program that is toggling a pair of pins once every half second.  The gist of the code is below:

void togglePins( const uint32 firstPin, const uint32 secondPin )
{
    nrf_gpio_cfg_output(firstPin);
    nrf_gpio_cfg_output(secondPin);

    nrf_gpio_pin_set(firstPin);
    nrf_gpio_pin_set(secondPin);
    
    while( 1 )
    {
        nrf_delay_ms(500);
        nrf_gpio_pin_toggle(firstPin);
        nrf_gpio_pin_toggle(secondPin);
    }
} // end togglePins()

This is pretty trivial code and works (sometimes).  The problem I'm having is that if I flash the SoftDevice and then my code the lines never seem to go low when connected to IAR through a SEGGER JLink.  I've tested this with both a logic analyzer and an oscilloscope and the lines just don't go down.  If I remove the debugger and reset the device the LED's toggle as expected.  After a while of being connected to IAR it will eventually work until I reset the SoftDevice again.  This definitely seems like something I'm not setting up correctly, but I've tried a ton of things and can't for the life of me figure this out.

If it makes a difference the two lines have external pullups on them and are connected to an LED driver.

[Hung Bui]

Hi,

In your while(1) loop, I don't see any delay meaning the pin will be toggle on every few cycles of the CPU. How should you expect the toggle should be ? or you want to achieve 8MHz toggling frequency (max toggling frequency of GPIO) ? 
I would suggest to add a delay by the end of the loop to give enough time for the pin to switch. 

[mbp83]

Bah, when paraphrasing my code in the snippet above I forgot the delay.  The delay is definitely in my code, I just missed it when putting it in the post above.  Thanks for catching that.  I'll edit it in the OP.

[Hung Bui]

Hi,

Thanks for the update. I assume by "connected to IAR through a SEGGER JLink" you meant to run in debug mode ? Did you step in the code or just let it run ? 

I actually don't know what could be wrong here. But could you try:

- not to do any BLE activity and check if the issue happens ? 

- Not to initialize the softdevice and check if the issue happens  ? 

- Try to access the GPIO register directly and skip the nrf_gpio library. 

- Please try to test using Segger Embedded Studio, so that it's easier for us to reproduce here 

[mbp83]

I'm sorry, I was sidetracked with some other stuff last week and missed your reply.

Stepping into the code or letting it run both faill to bring the lines down.  I've looked at the memory location as well associated with the GPIO registers and they are changing as expected.  As you suggested I removed the nrf_gpio APIs and just set the registers directly and this issue still persists.

I've removed all non-essential code that runs before this and it still occurs.

If I don't initiate the soft device the issue doesn't seem to happen, however when built and loaded onto a different device for the first time this hits again for a bit.  I can definitely work around the issue, I'm just curious why it's happening.

I've just jumped back on this and will likely spend a bit more time on it before moving on.

Thanks for your responses!

[Nguyen Hoan Hoang]

Which nRF chip are you using and which pins ?  On nRF52 there some reserved pins that require some special settings to be used as GIPO.  Check also if the pin is not conflicting with pins used by the DK.  Especially Uart pins that might be used for the nrf_log.  There might be some issue sas well if you are using the NFC pins as GPIO.