Stuck on power down due to GPIO

[TS Gowtham]

Hello,

We are using a nRF52832(peripheral) on a custom board and connecting it to a nRF51822(Central). The nRF52 has one GPIO connected to a button which is used to power down and power on the chip and all the components of the board. In the function for powering down the board, another GPIO which is used to switch the power to the board is set. 

void shutdown()
{
    //Few lines of nrf_gpio_pi_set and clear to power down other components
    
    nrf_gpio_pin_set(PIN);//PIN here refers to the GPIO which switches the power. This line causes the issue.
    
    nrf_gpio_cfg_sense_input(BUTTON, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);//To power on the board
    
    sd_power_system_off();
}

The power toggling works perfectly when the board is not connected to the nRF51822. After connecting the board to the nRF51, the power toggling works few times but after that it gets stuck. The board has to be reprogrammed or reset for it to continue working. On debugging the board, the program stops when a nrf_gpio_pin_set(PIN) is called. 

The code does not have any flash operations and I have read the FICR, UICR and Code sections before(when the board is working normally) and after(when the board is stuck) the issue. On running a diff, the files are identical.

Thank you

Gowtham

[Susheel Nuguru]

Since the power toggling works correctly when not connected to nRF51, it seems that this pin on nRF51 is configured with wrong pull. Can you keep the input configuration of this pin on nRF51 side with no pulls.

[TS Gowtham]

The issue is occurring on the nRF52, not the nRF51. None of the pins on the nRF51 are used here. The nRF51 is just used to connect to the nRF52 via BLE and get some data. FYI, the nRF 51 and nRF52 are not physically connected. 

[Susheel Nuguru]

ah, sorry, I thought they are physically connected.

Problems like this should be easily be detectable when you are running the debugger. But you say that "On debugging the board, the program stops when a nrf_gpio_pin_set(PIN) is called"  This should not happen since there is nothing in this functions that could make the CPU loop. Maybe your debugger is not showing the correct call trace? Which IDE and compiler are you using? are you debugging with the code that is compiled with 0 optimizations?

[TS Gowtham]

We are facing this issue with Visual Studio with VisualGDB and Segger Embedded Studio. I had placed RTT statements to check this issue.

[Susheel Nuguru]

it must be stuck somewhere else, not in the gpio_set function. Make sure that the app has not hardfaulted. Using RTT logs to narrow this down will be slow and tedious, start the debugger and run the code for sometime and halt the cpu, check the stack call trace.

[TS Gowtham]

Sorry for the late reply,

I have been trying to replicate the problem and check the stack call trace but SES debugger just stops randomly within 1~2 minutes without any error. So I'm unable to replicate the problem and check the stack call trace after the problem occurs on SES. Can you suggest any other tool or debugger I can use to check the stack call trace?

[Susheel Nuguru]

SES debugger just stops randomly after 1-2 minutes, this is in itself strange.

Are you sure that your project settings with memory is correct? seems like the debugger does not able to track the stack could be a hint that there is a stack corruption, which would explain why your debugger initially thought that the problem was in nrf_gpio_pin_set

[Susheel Nuguru]

Hi Gowtham, 

did you manage to solve this issue? I would appreciate it if you can help other forum members by giving a solution so that it can benefit them in future.