CODEWITHSUNDEEP
debuggingembeddedcortex-mcontiki-ng
Dingisoul
Dingisoul

Reputation: 21

Why stepping debug failed with cc2538dk on Contiki-NG, but success on RIOT?

I have a question about debugging with cc2538 on Contiki-NG.

I'm testing the 6LoWPAN function on both RIOT and Contiki-NG. While stepping through the code during debugging, RIOT works fine, but Contiki-NG fails - the application is just hello-world example.

I'm using the same debugging method for both:

  1. First, I connect JLink to the SmartRF06+cc2538EM.
  2. Then, I open JLinkDebugServer in one session and gdb in another.

When the gdb connection is established for Contiki-NG, it shows that the code steps into 0xdeadbeef. The JLinkDebugExe outputs:

Reading common registers: ERROR: Cannot read register 0 (R0) while CPU is running
Read register 'r0' (4 bytes) from hardware: 0xEFBEADDE
ERROR: Cannot read register 1 (R1) while CPU is running

Has anyone encountered this problem?

Any insights related to this problem or helpful information would be greatly appreciated.

Thanks, Dingisoul

how to fix contiki-ng to support stepping debugging? Are there any other debugging method? what part of configuration influence this problem? Why RIOT can success but Contiki-NG not?

Upvotes: 0

Views: 57

Answers (2)

Dingisoul
Dingisoul

Reputation: 21

I’ve discovered the root cause of the issue. Contiki-NG enables the watchdog timer by default.

When stepping through the code during debugging, it triggers the watchdog timeout, causing the entire system to reboot and resulting in the debugger fail.

I comment out the watchdog code, and now the debugger is working properly.

RIOT do not use cc2538’s watchdog, so the debug originally works well.

Thanks, all

Upvotes: 0

Clifford
Clifford

Reputation: 93566

Always read error/diagnostic messages from the top. It seems likely the the fundamental issue here is:

Reading common registers: ERROR: Cannot read register 0 (R0) while CPU is running

Given that statement, the value "read" from the register is not valid. It certainly does not indicate:

... that the code steps into 0xdeadbeef.

It indicates that the debugger has not halted the processor, has no control of it, and cannot read registers in that state.

Most debuggers have a "Connect Under Reset" or similar option. That may solve your problem, but whatever the issue is not related to the use of any particular RTOS - the debugger is entirely agnostic to what code is running - but everything to do with your debugger configuration which you have not elaborated on.

Upvotes: 0

Related Questions