Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Application won't start after DFU through RigDFU

I am trying to program a BMD-300 over a serial connection through the RigDFU bootloader. The module has been updated to the latest factory image.

I can compile the application fine with the soft device S132 using VisualGDB and BSP 14.2. I have selected the option to build a hex file as well and use it with Rigado's genimage.py tool, selecting only the application (-a switch). I then program the BMD-300 with their update tool, which completes successfully. The problem is that the application won't start. It doesn't have an external LFC so I followed the directions here but it didn't change anything.

Could this be because the I haven't included the bootloaders settings page? I'm not sure if I need it or not. What about SDK version? It looks like RigDFU is based on SDK 12. They have a config file that is used with the genimage tool that has these addresses in it:

[device]
family: nrf52
page_size: 0x1000
min_stack_pointer: 0x20000000
max_stack_pointer: 0x20010000

[softdevice]
compatible: True
min_address: 0x1000
max_address: 0x300C
size_address: 0x3008
end_offset: 0x2008

[bootloader]
compatible: True
min_address: 0x75000
max_address: 0x7E000

[app]
min_address: 0x1F000
max_address: 0x49000

py -3 genimage.py --hexfile in.hex --output out.bin --family config/nrf52832-sd132v3.x.0.cfg -a

py -3 dfy.py -s COM11 -i out.bin

Parents
  • I just took a look at the s132 migration document and noticed the application address change to 0x23000 for s132 v5.0.0. This most likely has something to do with it.

  • Yes, if the RigDFU bootloader jumps to 0x1F000 instead of 0x23000 when you have the S132 v5.0.0 flashed to the module, then this would likely be the cause. 

  • So I attempted to update the soft device to v6.0.0 and now it's not booting the bootloader. I made a new config (like the one above) with [app] min_address: 0x23000 and generated the soft device update with that.

    The serial dfu worked fine but like I said now I get nothing. Do you think [app] max_address needed to be updated to 0x4D000? That's the only other change they made between v2.0.1 and v3.x.0 configs when the soft device size changed.

    I know this isn't your tool but if you have some insight it would be appreciated.

    Edit:

    So I tried editing the other address and doing a dfu to my BMD-300 dev board and that didn't help either. At this point I'd gladly just switch to Nordic secure dfu serial. Problem is that I have breakout boards that I'd like to update but don't have access to the Cortex debugging pins right now (I need to get a Cortex debug breakout). I tired running the compiled secure dfu serial hex for PCA10040 through rigado's genimage.py but it complains it can't find the bootloader. I have the option to specify the location of the bootloader in the hex file to the tool but I'm not sure what it is. Do you happen to know?

    Edit 2:

    I changed the min_address for the bootloader to 0x73000 and got it to take it however after the serial DFU I didn't have any luck using nRFgo Studio or nrfutil to program the test softdevice_s132.zip. Neither utility was able to get a response from the bootloader. I made sure to use button 4 and reset to enter dfu mode. I'm running out of ideas aside from just flashing them all with the debug interface.

  • Just to clarify: The BMD-300 module is/was intially flashed with a bootloader(RigDFU) and the S132 v3.0.0 SoftDevice. You are trying to perform an application update, with an application that is build with which SDK?

    The serial bootloader in SDK v12.x uses the sd_flash api to store the image in flash, hence if you update the SoftDevice you need to be sure that the SoftDevice api used bootloader is compatible with the new softdevice, otherwise it will assert when you try to enable the SoftDevice. S132 v3.0.0 is not compatible with S132 v5.0.0 or v6.0.0. 

    The SD API compability requirement must also be met by the Application.

  • It took me awhile but I eventually came to that conclusion. I was using SDK 14.2/15 for the testing. No wonder it didn't work. Looks like I would need to stick to SDK 12 to continue using RigDFU or upgrade to the Nordic secure serial dfu to use a more recent SDK.

Reply Children
No Data
Related