Problem with nRF52 DK

RE: Problem with nRF52 DK

RK — Mon, 17 Aug 2015 23:36:28 GMT

That's what I did actually before I found the debug startup point, I copied the register set from SystemInit to the top of main, annoying but that worked fine too .

RE: Problem with nRF52 DK

Garth — Mon, 17 Aug 2015 23:33:52 GMT

Alright well I'll see what I can do as I continue working. Thanks for the insight!

RE: Problem with nRF52 DK

RK — Mon, 17 Aug 2015 23:23:53 GMT

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.

RE: Problem with nRF52 DK

Garth — Mon, 17 Aug 2015 21:56:56 GMT

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.

RE: Problem with nRF52 DK

RK — Sat, 15 Aug 2015 00:07:44 GMT

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.

RE: Problem with nRF52 DK

Garth — Fri, 14 Aug 2015 16:12:20 GMT

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

RE: Problem with nRF52 DK

RK — Fri, 14 Aug 2015 00:32:27 GMT

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.