Inconsistent behavior when debugging

RE: Inconsistent behavior when debugging

SmallerPond — Tue, 29 Jun 2021 19:57:25 GMT

I never had a need to make a new ticket because we (I think) found the problem. For the sake of posterity:

We have an external 3V3 that supplies an audio amp that requires enough power that it sometimes pulls the battery voltage down. This was causing the reset, but it was also causing the 3v3 regulator to go into boost mode. Then the battery would quickly rebound and the regulator would take a moment to switch back to buck mode. In the meantime it would cause a voltage spike over nRF52840 VDDH spec, which in turn must have done something to sometimes irrevocably latch the antenna into low power mode. Since it only happens rarely, it was very difficult to find.

Thanks again for your help!

RE: Inconsistent behavior when debugging

SmallerPond — Fri, 25 Jun 2021 13:38:10 GMT

Will do - thanks again Vidar!

RE: Inconsistent behavior when debugging

Vidar Berg — Fri, 25 Jun 2021 12:51:19 GMT

Thanks for confirming. Because this is sounding more like a HW issue I think it's better if you create a new ticket. My more HW oriented colleagues can give better advice when it comes to troubleshooting of poor radio performance.

RE: Inconsistent behavior when debugging

SmallerPond — Fri, 25 Jun 2021 12:14:40 GMT

Thanks Vidar! The 2cm behavior seems to persist forever with the device, regardless of what we do to it. Even if I erase the device and just run ble_app_blinky, we get the same behavior. And yes they only work within 2cm even after pairing - if I move them apart they lose connection and start advertising again.

RE: Inconsistent behavior when debugging

Vidar Berg — Fri, 25 Jun 2021 09:02:33 GMT

Thanks for the update. Good to hear that you found the problem. To read the RESETREAS register after the reset you must first tell the debugger to re-connect because it doesn't know that the connection has been lost. You can use nrfjprog for this.

Reading RESETREAS register after reset

nrfjprog --memrd 0x40000400 // Should return 0x0 if you encountered a brownout reset

With regards to your follow up question, do I understand it correctly that you achieve a more normal range as soon as you have managed to establish the connection and completed the pairing, or do you still have to keep them 2cm apart? I can't say I have seen that before. Are there any additional noise sources during this phase like high speed bus communication (SPI, UART, PWM, etc) that could possibly interfere with the RADIO?

RE: Inconsistent behavior when debugging

SmallerPond — Fri, 25 Jun 2021 01:38:21 GMT

Thank you, this ended up pretty much getting me there. We definitely ran into a voltage drop when the hardware was playing audio (amplifier IC draws around 2.5W) that must have been causing the debugger to drop the connection and the system to reset. I will say though that I was never able to check RESETREAS for this, all the registers always came up as 0xAAAAAAAA and 0xDEADBEEF for the CPU regs when I would try to connect after reset. I suspect that the J-Link is having trouble reconnecting to the unit after the voltage drop event for some reason.

Which brings me to a follow-up question that I am happy to put in its own thread if you like. We have a handful of devices (I think 6 or 8 of them now) that acted funny, and now function perfectly well, except that they only connect and pair to other devices if they are literally less than about 2cm apart, otherwise they do not connect at all. Everything else functions as expected and erasing them doesn't seem to have any effect. Have you ever seen this before? My guess is that they were subject to this voltage drop condition at some point and it somehow affected only that part of the device that supplies power to the antenna? Is this possible? It seems weird because I would be okay with the idea if it was a voltage spike (up), but a voltage sag/drop seems like it shouldn't have such an effect. Yet it seems to be somewhat repeatable for us. I think with a little work, I could maybe adapt a firmware that breaks nRF52840s in this manner.

RE: Inconsistent behavior when debugging

Vidar Berg — Thu, 24 Jun 2021 12:11:25 GMT

Hello,

I'm afraid I can't think of any good explanations as to why the devices would behave differently depending on where you placed the breakpoints. It's also uncommon to loose the debugger connection to the nRF device unless there is a HW problem (drop in supply voltage, bad connection, etc). For memory corruption bugs I'd usually expect to see either a hardfault exception, or worst case, a CPU lockup reset (you should have gotten the vector catch in that case).

If you haven't already, I would suggest that you try to monitor the RESETREAS register on boot to figure out what the reset source is.

Best regards,

Vidar