nrf51822QFAA DFU

[wim]

Hi

I have worked quite a lot with the nrf51822AC, and some time ago I got the OTA bootloader working in my projects on a custom board.

However, now I am trying the same one a board with the nrf51822QFAA (so less RAM), but I do not get the device to start up when including the bootloader.

I am working still with SDK7.2 and softdevice 7.3.0.

I have spent quite some time on this now, and still do not really know what I should do.

I have started from a clean SDK, took the example project for the bootloader in Keil, fixed the project definition first (there is a missing link to core_cm0.h)to make it compile, adapted the board definition file to match my custom hardware, adapted the memory ranges in the projects (IRAM1 size and IRAM2 start), adapted the code to use the LF RC oscillator (no 32khz crystal on board) and compiled the project. When I load only my application and the softdevice, using JlinkExe, it starts up fine, when I load softdevice, application and bootloader, nothing happens.

What am I doing wrong? Can anyone help?

[wim]

Hi Bjorn,

I found the issue - my code and memory configurations were ok, but in the JLINKExe command line options I used the wrong device type, so I guess it was written to the wrong position in flash or something; all seems to work now, except for 1 thing: if I set the device name in the DFU bootloader code (using the sd_ble_gap_device_name_set() function) to a string longer than 8 characters, the bootloader crashes; I have been looking for the root cause of that crash, but did not really find it yet; where does this limitation come from? because in my normal application, I use longer names without a problem, and wanted to use more or less the same name if possible

[bjorn-spockeli]

Yes, that would explain why it did not run properly. Are you able to check if sd_ble_gap_device_name_set() returns NRF_SUCCESS or an error code?

[wim]

to be honest, I never debugged the bootloader code, just compile and flash, so I am not really sure; what I do know is that it is probably not NRF_SUCCESS, as the reset is explained by the ERROR check; i just traced it down to the name length: if it is 8 or smaller, all is ok, if it is > 9, I get a reset;

[bjorn-spockeli]

@wim: I think is because the advertisement packet is restricted to a payload 31 bytes. The packet already contains the 128bit(16bytes) UUID of the DFU service in additions to some additional bytes so if you set a very long device name, then you will exceed 31 bytes and ble_advdata_set() in dfu_transport_ble.c will return an error which in turn will cause a reset.

[wim]

that makes sense, this was my thought as well; so I guess a 16 character name is not feasible

[bjorn-spockeli]

No, you will not be able to fit the UUID of the DFU service and a 16 character name in the 31 byte payload of the Advertisement package.