Changed from S112 to S113 and now DFU only partially works

[Gordon]

Hi!

We recently developed some firmware using S112 on a nRF52810 but realised that we needed data length extension, so changed to using S113.

Previously everything worked great (including DFU) with S112, and after changing softdevice to S113 (and the relevant linker/Makefile parts) the main application is now going great.

However DFU updates are now behaving very strangely. The bootloader starts and can be connected to just fine. However when you try to upload a firmware file, it updates just a tiny amount and then disconnects. It seems as if the device itself locks up, but it seems it isn't locking up on a hardfault or application error (at least according to GDB).

nRF Connect's log shows that 'Data Object 1/12' was sent and executed, but after 'Data Object 2/15' and 'Uploading firmware...' are sent, the device just disconnects.

Any ideas what might be the matter, or how to debug this further? Thanks!

[Gordon]

After an hour of trying to build the bootloader with some logging, I finally succeeded in getting it outputting something (albeit without printf):

Writing settings...                                                            
Erasing old settings at: 0x%08x                                                
nrf_fstorage_erase(addr=0x%p, len=%d pages), queue usage: %d                   
nrf_fstorage_write(addr=%p, src=%p, len=%d bytes), queue usage: %d             
Backing up settings page to address 0x%x.                                      
Writing settings...                                                            
Erasing old settings at: 0x%08x                                                
nrf_fstorage_erase(addr=0x%p, len=%d pages), queue usage: %d                   
nrf_fstorage_write(addr=%p, src=%p, len=%d bytes), queue usage: %d             
Writing valid init command to flash.                                           
Request handling complete. Result: 0x%x                                        
Set receipt notif                                                              
Handle NRF_DFU_OP_RECEIPT_NOTIF_SET                                            
Request handling compl...

So shortly after 'Request handling complete' it would appear to spontaneously restart...

[Vidar Berg]

Hi,

Are you testing this on an actual 52810 target or are you emulating the nRF52810 on a 52832 board? I'm asking because the update should have been rejected already from the start because there is not enough flash to store another copy of the Softdevice in flash as illustrated by the "Memory layout" and "Dual-bank updates" section of the SDK documentation.

Over-the-air updates of the Softdevice is not supported on this part because of the memory constraints, unfortunately.

Best regards,

Vidar

[Gordon]

Hi Vidar,

Sorry, I wasn't too clear about that. I'm testing on an nRF52810. I am not updating the softdevice via DFU though.

I have S113 softdevice already and am trying to update the application, which is 58kB. 

DFU update worked great with identical code on S112. I just:

• Updated the softdevice
• updated every reference to S112 in the makefile to S113
• changed the linker files to the correct RAM offset (and flash offset in the case of the app)

This worked fine for the main application, however afterwards the bootloader has had this strange issue where it only seems to accept the first object and then reboots. Maybe the bootloader thinks the app's base address is still at where it would be for S112? I'm not sure where that would be set though.

[Surya]

I am updating BL in S112, and after 2 Objects sent successfully, it is failed(Disconnected).

https://devzone.nordicsemi.com/f/nordic-q-a/77061/updating-boot-loader-otadfu-failed-with-error-8-0x08-gatt-conn-timeout

Updating app is working fine. I didn't got any reply form support but this following it may help you

[Gordon]

Hi, Thanks, but I don't think size is the answer here... In my case:

The nRF52810 has 192kB RAM.

* SD 113 takes 112k (0x00000 - 0x1C000)

* App has 48k (0x1C000 - 0x28000)

* Bootloader is 24k (0x28000 - 0x2E000)

* Boot info stuff is (0x2E000 - 0x30000)

Even if the size was wrong I guess the bootloader should reject it, not just completely lock up.

Just to add, when I debug all I can really see when it's stopped is it seems stuck at address 0x0001ae3e (in the softdevice).