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.

[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.