When enabling RTT the program runs until the first NRF_LOG_PROCESS() Verification and then directly in the HardFault-Handler

[matthk]

Hello,

our project which started 7 years ago with SDK13.0 has been migrated some time ago to SDK 15.3 and now to SDK17.1. At the beginning we were quite happy with the RTT functions, but since a certain time (maybe beginning with SDK15.3) we can not use it any more because the firmware runs directly to the HardFault handler.

We have verified and updated our code already using some tickets from this forum like 

• Case ID: 123565: RTT & RTT disable sdk 12/13 nRF52832/nRF52840
  or
• Case ID: 213834: RTT Logging not working when building with ARM GCC
  or
• Case ID: 128187: RTT logs broken in SDK14.2 with GCC

but still RTT does not work.

In sdk_config.h we have defined

NRF_LOG_ENABLED = 1

NRF_LOG_BACKEND_RTT_ENABLED = 1

NRF_LOG_BACKEND_SERIAL_USES_RTT = 1

NRF_LOG_BACKEND_SERIAL_USES_UART = 0

I have joined a screenshot from the debugging phase where the first NRF_LOG_PROCESS() check is done, at the left side of the screenshot

you can see how the µC runs to the HardFault Handler.

We use the nRF52840 and gcc GNU_ARM/9 2020-q2-update.

What can we do to make RTT run? 

BR, matthK

[Sigurd]

Hi!

You should check the hardfault info to see why it hardfaulted.

See this post on how to enable the hardfault handler library:

 RE: Catch HardFault 

 

[matthk]

Hi Sigurd,

following the description I have enabled the hardfault handler library, but I don't see any difference when running the CPU. Where can I get the needed information? 

[matthk]

Hi Sigurd,

I have the following data:

SEGGER J-Link GDB Server V8.18 Command Line Version

JLinkARM.dll V8.18 (DLL compiled Mar 5 2025 14:42:43)

Command line: -if swd -device nRF52840_xxAA -endian little -speed 2000 -port 2331 -swoport 2332 -telnetport 2333 -vd -ir -localhostonly 1 -singlerun -strict -timeout 0 -nogui

-----GDB Server start settings-----

GDBInit file: none

GDB Server Listening port: 2331

SWO raw output listening port: 2332

Terminal I/O port: 2333

Accept remote connection: localhost only

Generate logfile: off

Verify download: on

Init regs on start: on

Silent mode: off

Single run mode: on

Target connection timeout: 0 ms

------J-Link related settings------

J-Link Host interface: USB

J-Link script: none

J-Link settings file: none

------Target related settings------

Target device: nRF52840_xxAA

Target device parameters: none

Target interface: SWD

Target interface speed: 2000kHz

Target endian: little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link OB-nRF5340-NordicSemi compiled Feb 11 2025 17:15:35

Hardware: V1.00

S/N: 1050281280

Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB

Checking target voltage...

Target voltage: 3.30 V

Listening on TCP/IP port 2331

Connecting to target...

ERROR: Could not connect to target.

Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...

Shutting down...

Shall I try to modify the settings to have them identical to yours?

BR, matthK

[matthk]

I have just modified the non-equal parameters, but still the same result:

SEGGER J-Link GDB Server V8.18 Command Line Version

JLinkARM.dll V8.18 (DLL compiled Mar 5 2025 14:42:43)

Command line: -if swd -device nRF52840_xxAA -endian little -speed 1000 -port 2331 -swoport 2332 -telnetport 2333 -noir -localhostonly 1 -strict -timeout 5000 -nogui

-----GDB Server start settings-----

GDBInit file: none

GDB Server Listening port: 2331

SWO raw output listening port: 2332

Terminal I/O port: 2333

Accept remote connection: localhost only

Generate logfile: off

Verify download: off

Init regs on start: off

Silent mode: off

Single run mode: off

Target connection timeout: 5000 ms

------J-Link related settings------

J-Link Host interface: USB

J-Link script: none

J-Link settings file: none

------Target related settings------

Target device: nRF52840_xxAA

Target device parameters: none

Target interface: SWD

Target interface speed: 1000kHz

Target endian: little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link OB-nRF5340-NordicSemi compiled Feb 11 2025 17:15:35

Hardware: V1.00

S/N: 1050281280

Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB

Checking target voltage...

Target voltage: 3.30 V

Listening on TCP/IP port 2331

Connecting to target...

ERROR: Could not connect to target.

Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...

Shutting down...

I have the impression, that the communication between PC and the debug (Segger) chip works, but the communication at the PCA10056 between the Segger chip and the nRF52840 might be problematic. What do you think?

BBR matthK

[matthk]

Hi Sigurd,

I have just looked for another PCA10056, and with this and your settings finally this works. I can compile, download and run the application - thanks for your support!

The only thing which doesn't work correctly is when setting a breakpoint in a line and let run then the stop is not in the selected line but 4 or 5 lines later - do you have any idea how to solve that?

Now I will continue migrating my firmware application from our target electronics to the PCA10056; finally what we want is to be able to search a special bug with trace functionality...

For this I will keep SDK15.3 to create a minimum of new bugs while migration to PCA10056. 

If you have any special recommendations please feel free to send them to me.

BR, matthK

[Sigurd]

matthk said:

I have just looked for another PCA10056, and with this and your settings finally this works. I can compile, download and run the application - thanks for your support!

Great!

matthk said:

The only thing which doesn't work correctly is when setting a breakpoint in a line and let run then the stop is not in the selected line but 4 or 5 lines later - do you have any idea how to solve that?

Could be because of optimization level for the build, see this post:  nrf52810 Eclipse Debug Problems

[matthk]

Yes, the modification of the optimization from 3 to 0 brought the expected behavior -thanks a lot!

Now I can continue with the migration of our firmware to PCA10056...

Have a nice week-end!

BR, matthK