Attachments (0)
Nordic Case Info
  • Case ID: 246306
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

HardFault when writing/erasing flash unless RTT debugger active

plippo

Hi,

I found one older question (7 months ago) with the same problem but that had no answer.

Situation:

- SDK 15.3, s132 v6.1.1
- The softdevice has been enabled and ble stack initialized
- Code needs to erase and write a flash page (settings) unless already initialized

As soon as the flash erase (or write) is performed, the app crashes unless the RTT debugger (RTT viewer or Ozone) is attached. If the debug-connection is active everything works.

My code stores the hardfault information into noinit memory and prints it to RTT on next reboot, so when I attach a RTT connection to continuously rebooting MCU, I get:


00:00:00 *CPU FAULT*
00:00:00 - HFSR = 40000000
00:00:00 - CFSR = 400
00:00:00 - MMFAR = e000ed34
00:00:00 - BFAR = e000ed38
00:00:00 - R0 = 2000587c
00:00:00 - R1 = 1
00:00:00 - R2 = 76b6f
00:00:00 - R3 = 4001e400
00:00:00 - R12 = 0
00:00:00 - LR = 200058ac
00:00:00 - PC = 77141
00:00:00 - PSR = 0

PC is in the bootloader memory though the application code is clearly being run (seen from power curve).


Same thing happens with both Debug & Release builds and I'm running out of ideas...

Parents
  • 0

    Hi

    Does this occur on a development kit (DK) or a custom board? Also, application are you running on your board, is it based on one of the SDK examples?

    You can try to enable logging via UART if possible, that way you should be able to see the logs without being in debug mode.

    Best regards,

    Simon

  • 0 in reply to Simonr

    It's a custom board (see: www.movesense.com). 

    I'll try to setup the UART debugging and see what's happening. Unfortunately we have communication protocol setup on top of UART so it may take some time to get it to work.

    If you have any idea what could be different in MCU when RTT connection is up, please let me know. I'm assuming it's timing related but maybe not...

  • +1 in reply to plippo

    Maybe this page is protected by the BPROT? The protection gets disabled by default in debug interface mode, which could explain the behavior you are seeing. 

  • +1 in reply to Vidar Berg

    That was it! Very big THANK YOU! (A simple debug print of BPROT config registers confirmed this)

    It looks like the default DFU bootloader marks all but the 0x7F000 page above bootloader start protected. We used to have a bootloader starting from 75000 so that debug version would fit. Unfortunately the DFU cannot change the bootloader start address when updating SD + BL, so now were stuck with it and had to use the 7D for our settings page. 

    So all I have to do is to modify our bootloader code to not mark the needed pages protected and we're good to go.

    Thank you for a swift solution!

Reply
  • +1 in reply to Vidar Berg

    That was it! Very big THANK YOU! (A simple debug print of BPROT config registers confirmed this)

    It looks like the default DFU bootloader marks all but the 0x7F000 page above bootloader start protected. We used to have a bootloader starting from 75000 so that debug version would fit. Unfortunately the DFU cannot change the bootloader start address when updating SD + BL, so now were stuck with it and had to use the 7D for our settings page. 

    So all I have to do is to modify our bootloader code to not mark the needed pages protected and we're good to go.

    Thank you for a swift solution!

Children
No Data
Terms of service