DFU Example hardfaults

[Joep]

After spending substantial time without luck I will drop my question here.

Setup

• nRF5_SDK_12.1.0_0d23e2a -> bootloader_secure debug target
• nRF51 & nRF52
• IAR 7.60.2
• nRFgo Studio 1.21.1.3
• Segger 6.10m
• Tried SD s132_nrf52_3.0.0_softdevice.hex and s130_nrf51_2.0.0_softdevice.hex
• PCA10040, PCA10028 and our own target

Actions

• Flash SD in nRFstudio, flash bootloader in IAR -> hardfaults after break->run
• Flash SD & bootloader in nRFstudio, debug w/o download in IAR -> hardfaults after break->run

Also tried flashing with nrfjprog.

If I let the target run (so no break/run in debugger) the target seems to run "fine"

Output

Blockquote :INFO:Inside main :INFO:In nrf_bootloader_init :INFO:In real nrf_dfu_init :INFO:running nrf_dfu_settings_init :INFO:Enter nrf_dfu_continue :INFO:Single: Invalid bank :INFO:Enter nrf_dfu_app_is_valid :INFO:Return false in valid app check :INFO:In nrf_dfu_transports_init :INFO:num transports: 1 :INFO:vector table: 0x00073000 SDH:INFO:sd_ble_enable: RAM START at 0x20002c00 SDH:WARNING:sd_ble_enable: app_ram_base should be adjusted to 0x20002798 SDH:WARNING:ram size should be adjusted to 0xd868 :INFO:After nrf_dfu_transports_init :INFO:------- nrf_dfu_flash_init------- :INFO:Waiting for events :ERROR:received a fault! id: 0x00000001, pc: 0x&08x

Sometimes the device restarts (looking at RTT output) w/o hardfault catch.

Please advice!

Wkr, Joep

[Alex]

You can't run after break if SD started. It is how it works. So if you put break point before SD started you can continue without hard fault. After SD started it is impossible.

[Joep]

Thanks for your answer Alex, but how on earth I would debug a program then???

[Alex]

RTT debug output.

[Joep]

That is going back 10y in time... When we debug an application not using a bootloader we can debug w/o problems, also using the Softdevice. Ofcourse stopping the program while SD is busy may cause communication issues due to timeouts, but hardfaults?

[bjorn-spockeli]

Hi Joep,

when the softdevice is enabled and there is BLE activity then it is difficult to debug an application since the softdevice interrupts have the highest priority. Thus, when a softdevice interrupt triggers the real-time requirements will be broken by the breakpoint you set in your application, it will assert immediately and this is an unrecoverable fault unless you reset chip.

It is possible to set the PRIMASK bit, which allows you to debug until the next sd_ - function call, you can read more about it in the posts I have linked to below.

devzone.nordicsemi.com/.../

devzone.nordicsemi.com/.../

Best regards

Bjørn