Application crashing during UART communication after flashing SoftDevice+Bootloader+Application

[MichaelKesemHealth]

Hello,

I am trying to implement ble DFU on our custom nRF52832 board. Up until now we have had no issues with our application running  as SoftDevice+Application but some issues have arisen with the implementation of the DFU. 

Controllers:

• Rigado BMD-350 Evaluation Board

• BMD 300 with a custom board

Family: nRF52832

pca10040

IAR IDE: used to compile our custom firmware

Keli: used for compiling the secure bootloader

SDK: 15.0

SoftDevice: S132 v6.0.0

We are trying to implement ble DFU functionality to our firmware. We followed the examples and managed to successfully implemented the secure bootloader located under: SDK15.0.0\\examples\\dfu\\secure_bootloader
pca10040_ble using my own generated crypto keys. This compiles successfully.

We then compiled our application and prepare a DFU flashable package using:

1 nrfutil pkg generate --application IUFlow.hex --application-version 1 --application-version-string "1.0.0" --hw-version 52 --sd-req 0xA8 --key-file private.key app_dfu_package.zip

This gives me a flashable zip.

I then prepare the board with the SoftDevice and Bootloader as follows:

Flash the SoftDevice

1 nrfjprog -f nrf52 --program s132_nrf52_6.0.0_softdevice.hex --chiperase

Flash the Secure Bootloader

1 nrfjprog -f nrf52 --program nrf52832_xxaa_s132.hex

This results in boards going into DFU mode and the advertising as DFUTarg.

I am then able to successfully connect to the board using a Android device with the nRF Connect app and I am able to select the previously created flashable zip which is then sent to the device and the device loads the app and it starts running as normal.

Our application uses UART for Bluetooth communication to other devices which relates to when the issues occurs. Other devices are able to connect the board running the application as normal and even read it but the issue begins when communication with the device starts.

Reading from the device seems to work but any attempt to write to the device will cause it to freeze until reset. I do not think its related to flash writing as we have managed to successfully write to flash without the communication and it does not crash. Device is cashing ONLY during write events that happen through UART communication.

This would indicate that the issue is with the application but if only the SoftDevice + application are flashed then board runs fine with no issues what so ever. As far as I know the bootloader should not have this impact on a working application so I am a bit confused as to what the problem could be.

So I have a few questions based on this:

• Are there any config files on the bootloader side/applications side that might not be aligned that might cause such behaviour.

• From my investigations i believe that memory locations for the ROM and RAM might have something to do this with this behaviour but I have not been able to successfully make the issue go away by changing them. But i might have done something wrong.

• Is there anything else that might be quiet obvious that I might be missing? I have tried many things (that i havent mentioned here) but haven managed to get very far.

I am not the original developer of our application so a lot of the details about the original application have been lost in translation and I have had to reverse engineer the architecture of our application so I am unsure of some of the specifics but I will try to offer any additional information as required about the setup and configuration. It is possible that the original developer has done some non standard things that are not compliant with how the bootloader works (or nordic SDK) but I would like to rule out any other issues as well. He tends to write code in a non standard way (non standard to nordic) so I have contacted him as well but the issue could still be something else.

Any feedback or suggestions would be greatly appreciated.

Kinds Regards,

Michael, 

[MichaelKesemHealth]

Hi Einar,

Thank you for your response. By some fluke the controller worked after one flash but attempting to read system variables set on the device gave very strange data. This along with your mentioning of memory layouts prompted me to go looking how our apps layout  layout and what correct way to do its

After a bit of digging and lots of testing I found that there was a whole chunk boot loader memory locations being overwritten by the application during run-time which is what was happening during the UART read. The app would try to read/write override bootloader memory locations causing weird unpredictable behaviour and mostly crashing. So I shifted all these variables down to stay clear of the bootloader and suddenly everything WORKS.

Thank you so much for your response, its been a very challenging project as I have been carrying on from another engineer without much documentation on what had been done before.

:)