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

I use nrfjprog tool to load the combine hex file to PCAl0040. 

Brian

[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

[Einar Thorsrud]

Hi Brian,

I see. Then I have some more questions:

• Is the application correctly built using the S332 header files, preprocessor defines specifying S332 etc.?
• And do you test with S332 in both cases, or could it be that you are using an old project for S132 and that that is what you build for and is programmed automatically by SES?
• Does the bootloader settings page contain the correct hash for the application?
• If the above points are not the problem, can you test with the debug build of the bootloader, that includes RTT logging? The RTT logging from the bootloader is often very useful for understanding what is going on.

[brian]

Hi Einar

. I think the application is correct. if I program the combine hex file first, then debug the application using segger, It work well.

. I am sure that both  applicaion and bootloader using S332 are different from S132s. 

. The bootloader setting page is as below. I am not sure if it is correct.

nrfutil settings generate --family NRF52 --application ble_ant_app_hrm_pca10040_s332.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 bl_setting.hex

. The log of S332 bootloader is as below.

<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

Thanks.

Brian

[Einar Thorsrud]

Hi Brian,

Thank you for the updates. Is this log from the problematic case, when you program the merged hex via nrfjprog? Looking at the log the bootloader starts the application, so this indicate that there is no problem with the bootloader or bootloader settings. I am a bit puzzled about why the log states that it is advertising if it should not enter DFU mode, though.

Can you debug the application to try to see what is happening there? Alternatively, use logging in the application as well? (Note that RTT logging in both the application and bootloader can be problematic, and while it can be fixed, it might be easier to just use UART logging from the application if you have problems.)