SDK 16 S332 Bootloader

[brian]

Hi

After getting  SDK16 , we have tried to load a combined hex file with  bootloader + S132 V7 + application with dfu + bootloader setting page to PCA10040. And It work well, dfu is ok. 

And then We update bootloader and application form S132 to S332. It seems working well, while only programming bootloader and S332. but If we load a combined hex file with bootloader,softdevice,applcation,and bootloader setting page, It can't work, application isn't advertising. But If we debug the application( with S332 and bootloader), then it work well. Is there any setting we miss? We also use nfjprog --readregs to get register value while program stuck. The PC is 0x0003AB02 and check with map file, It is stuck at

_do debug_operation

0x000000000003aae8 __do_debug_operation
0x000000000003ab18 __text_end__ = (__text_start__ + SIZEOF (.text))
0x000000000000a744 __text_size__ = SIZEOF (.text)
0x000000000003ab18 __text_load_end__ = __text_end__

Brian

[Einar Thorsrud]

Hi Brian,

I have some questions since I am not entirely sure how to interpret what you do.

• You write that "If we load a combined hex file with bootloader,softdevice,applcation,and bootloader setting page, It can't work, the application isn't advertising". Does this mean that you merge everything together, and then upload via a debugger and try to run it, and hen it fails?
  • So there is no DFU in the loop here?
  • And then by just attaching a debugger and starting a debug session it works, with the exact same content in flash?

By the way, the bootloader .hex file you uploaded seems reasonable to me. Also, any content in the bootloader .hex for the UICR (typically bootloader start address), will be stripped away by nrfutil when it generates the DFU zip package, so it should not cause problems.

Einar

[brian]

Hi Einar

The combine hex file are include bootloader, application with dfu, S332 V6.1.1, and bootloader setting page. PCA10040 doesn't work after programming the hex file using nrfjprog tool. It isn't advertising.

And then I used segger studio to debug the application, it work well.

Brian

[brian]

Hi Einar

while using segger to debug application , the RTT log are as below

UART started.
<info> app: Setting vector table to bootloader: 0x00072000
<info> app: Setting vector table to main app: 0x00030000
<info> app_timer: RTC: initialized.
<info> app: Debug logging for UART over RTT started.

while using nfjprog to programm S332 and bootloader (without segger debug), the RTT viewer log are as below

<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<info> app: Boot validation failed. No valid app to boot.
<debug> app: DFU mode because app is not valid.
<info> nrf_bootloader_wdt: WDT is not enabled
<debug> app: in weak nrf_dfu_init_user
<debug> app: timer_stop (0x20005984)
<debug> app: timer_activate (0x20005984)
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> nrf_dfu_ble: Setting up vector table: 0x00072000
<debug> nrf_dfu_ble: Enabling SoftDevice.
<debug> nrf_dfu_ble: Configuring BLE stack.
<debug> nrf_dfu_ble: Enabling the BLE stack.
<debug> nrf_dfu_ble: No advertising name found
<debug> nrf_dfu_ble: Using default advertising name
<debug> nrf_dfu_ble: Advertising...
<debug> nrf_dfu_ble: BLE DFU transport initialized.
<debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
<debug> app: Enter main loop

But, if I program combine hex file (bootloader, S332, application, bootloader setting page) to PCA10040, there is nothing logged in rtt viewer.

Brian 

[brian]

Hi Einar

Attached the combine hex file. 

Brian

Final.hex

[Einar Thorsrud]

Hi Brian,

Looking at the RTT log from the failing case, this line is interesting:

<info> app: Boot validation failed. No valid app to boot.

It is clear that boot validation fails, and therefore the bootloader does not start the application. This failure indicates that the hash of the application region does not match the CRC that is specified in the bootloader settings page. So the problem is one of two:

• either, the hash in the bootloader settings is incorrect,
• or the application regions have been modified by something (for instance writing to flash within the application region).

Can you dump the flash memory in both cases, so that we can see how the flash differs in the two cases? You can dump the entire flash memory using "nrfjprog.exe --memrd 0 --n 0x80000 > flash_dump.txt".

Also, you can verify that booting works by changing the bootloader to always consider the app valid by chancing the app_is_valid() function in nrf_bootlaoder.c in the bootloader to always return true.

[brian]

Hi Einar

The RTT log is not from the combine hex file. It is logged when I only burn S332 and bootloader.

PCA10040 seems can't work with combine hex file, there are nothing logged.

I have dumped  the entire flash memory,the dump file is attached, and tried to change app_is_valid() to always return true, but it still can't work.

Brian

flash_dump.txt

[Einar Thorsrud]

Hi Brian,

I see. I was reading the last reply too quickly.

Let's recap the boot sequence:

1. Execution starts in the MBR
2. MBR checks bootloader start address (in end of MBR page or UICR register)
3. If the BL address is unset, do not jump to the bootloader, but instead start the application (which is right above the SoftDevice). This should not happen.
4. If BLE address is set, start the bootloader. We know this happens when you program SoftDevice and Bootloader from SES, since we see the RTT logs.
5. Bootloader continues to start application etc.

So the question is what goes wrong in step 1-4 above? To see this, it would be interesting to see a flash dump of the working case (where you programmed from SES) and the failing case (where you programmed the .hex file), so that the files can be diffed and the relevant sections of the flash inspected.

Can you make two flash dumps, one showing the working case and one showing the non-working case? Both should be done with the same command ("nrfjprog.exe --memrd 0 --n 0x80000 > flash_dump.txt"). That way any difference in the relevant region (MBR, SoftDevice or bootloader) should hopefully stick out. Please also provide dumps of the UICR for both cases as well, which you can get with "nrfjprog.exe --memrd 0x10001014 --n 4".

If this does not give any results, it would be interesting if you could upload complete projects for both the bootloader and application (you can do so in a private case and refer to this thread if you like).

Einar

[brian]

Hi Einar

The falsh dump file of working case using segger debug is the same with the non-working case. please see the attached file. And the UICR dumps of working and non-working case are also the same as below, 

-----------dump-------------------
0x10001014: 00072000 |. ..|

And how to provide the complete project as in a private case?

Brian

flash_dump_segger.txt3681.flash_dump.txt

[brian]

Hi Einar

I have created another private case, and attached my complete project.

Thanks.

Brian

[Einar Thorsrud]

Hi Brian,

Thank you. I suggest we continue in the private thread for now.

Einar

[Einar Thorsrud]

This issue was resolved in the private case. It was related to a bug in the application and had nothing to do with the bootloader or S332 specifically.