Conflict with SoftDevice on P0.12

[SteveHx]

Working application, using S132 SoftDevice, new variation of the application. Using UARTE, with P0.12 assigned as RxD. Something in the SoftDevice is grabbing P0.12 and setting it as an output and low. If I call uart_init() early enough to grab the pin, the softdevice crashes and my code never starts running. GPIO is definitely not grabbing it; indeed, I can't even set it as an output and set it high. What other peripheral is likely to be grabbing that pin? Nothing I can find in any of the source code should do anything with it.

Even more mysterious, we have 3 units (out of over a dozen in this batch) that configure the pin correctly. A timing difference in the startup, perhaps?

Steve Hendrix

[Vidar Berg]

Hello,

The only time the Softdevice can control GPIOs is when you use the PA/LNA control feature, but even then it is the application that is responsible for assigning the pins to the softdevice, it will not grab the pins by itself.

the softdevice crashes and my code never starts running

Could you please try to provide any more details about this crash? If you have debug logging available on this device, the easiest way to get more information about the crash is to build the project with "DEBUG" defined in the list of preprocessor symbols and let the app_error_fault_handler() print the crash log.

Thanks,

Vidar

[SteveHx]

Perhaps it's not the softdevice that's messing with P0.12. But clearly *something* is. I inserted 1K in the line between P0.12 and the external device that drives it, and moved my test code to the very beginning of main(). My test code configures P0.12 as an output and then toggles it high and low for a brief while, long enough to see on a scope. It swings between 0V and 0.2V, with the chip running at 1.8V. The adjacent pins (P0.11 & P0.13) and the traces connected thereto and effectively guarding the P0.12 trace are set to a high level, so no chance of leakage there. Setting those traces low does not impact the signal at all.

So what else in the chip, likely via something in the Nordic startup code, could be causing P0.12 to be loaded down so severely that my application cannot work?

[SteveHx]

Further info: Based on in-circuit measurements, with 1K in series with the line that should be driving P0.12, something inside the nRF52832 is sinking about 1.8 mA, and thus under these conditions presenting about 83 ohms to Gnd. What could be doing that, and how do I fix it?

[Vidar Berg]

It is starting to sound more like a HW issue. Are you seeing the same across multiple boards, or have you only tested this on one board thus far? A damaged ESD diode could potentially explain the low resistance to GND. 

[SteveHx]

I keep thinking HW as well, but it's consistent across 9 units of 14 tested. I also tested by pulling nRESET low to force the nRF52832 into reset, wherein all GPIO pins should float, and there's still something pulling it down.

The line is not externally exposed to any ESD possibility. On the units not failing, the signal swing there is about 0-1.5V (Vcc=1.8V) and is a driven by a normal MOS output powered by the same 1.8V supply. The only place the trace goes out of sight is a thru-hole testpoint inline in the trace from the driving module, 28 mil hole with 40 mil pads both sides. The two inner layers it goes thru are Vcc and Gnd. I have a unit in process to cut the trace loose from that testpoint and bridge with visible wire atop the board, but it's really tedious with 7 mil traces and a total trace length of only about 10mm. Still open to any other ideas.

[Vidar Berg]

The GPIO is not guaranteed to be reset until you release the nRESET signal. I don't remember specifically for the nRF52832, but some nRF52 variants will retain the GPIO configuration from before the reset for as long as the nRESET signal is asserted. To be absolutely sure the GPIO is in the reset state and not reconfigured by any code, you could perform a chip erase followed by a reset and repeat the measurement after. The ESD diode may become damaged if the device has been back powered through this pad.