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

[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.