Problem with nRF52 DK

[Garth]

Hi all,

I just received my nRF52 DK and started attempting to run examples on it. I am having an odd trouble that the LED2 is always lit after programming the board, no matter the application. Additionally the LED4 is dimly lit. Does anyone have any clue what could be causing this? It is leading me to believe there may be more underlying issues with the rest of the board as well.

Thanks in advance!

[RK]

Read the anomaly about trace being activated when debug is activated. The trace pins, rather strangely I thought, are the same ones chosen for LED2 and LED4, LED2 is connected to the pin with trace data, so it's high, LED4 to the pin with trace clock, so it's 50% duty cycle lit.

The current SystemInit code turns trace off to work around that anomaly, unless you've defined the ENABLE_TRACE define, however that has to run after your debugger puts the chip into debug mode otherwise it has no effect and when the chip is later put into debug mode, the trace gets re-enabled and nothing turns it off again. I had to fix a property in my build environment (Crossworks) to get into debug mode before SystemInit.

And if you are defining the ENABLE_TRACE macro, then you're getting what you asked for, trace enabled, and those two LEDs are somewhat less useful.

[Garth]

I am also working in Crossworks. Would you be able to detail your workaround to get into debug before SystemInit?

[RK]

oh sure - sorry I would have put it in text but I never thought anyone else would be using Crossworks.

It's a standard Crossworks feature, which you've probably never seen, I hadn't until I asked a question a while ago. If you check properties and search for 'start' you should find one called 'Startup Completion Point', it's saved in the project file as 'debug_startup_completion_point'' and it's the place debug and debug IO (eg RTT) is enabled, it's also useful when using Segger RTT else it doesn't start logging.

Set that to 'SystemInit' and it should enable debug at the start of that routine, which turns trace on (anomaly) just in time for the code there to turn it off again.

I assume most of the other tools turn debug on right at the very start after reset and don't wait for some code to have finished running first, so they are already in debug/trace mode when SystemInit runs.

[Garth]

Thanks for the quick response and help! It seems that immediately as I connect to the board in CrossWorks the trace is activated and remains active until I reset the board by powering off and on. Even after running/debugging a program to the board with the startup point specified to be 'SystemInit' I am still seeing the issue. If I power cycle the board the program runs as expected with the trace then not being displayed (obviously because the debugger isn't messing it up then). But regardless, it seems that I am unable to debug without this problem still.

[RK]

That's the fix which is working for me. You could also, annoying though it is, stick a breakpoint in SystemInit. Or else repeat the logic from there which turns trace off at the start of main.