Hi,
I am developing a bootloader for a custom board with the nRF52840 (nRF5 SDK v15.0.0 and SEGGER Embedded Studio V3.30) where we have no other option but to engage DFU using the uart. The uart is also used in the actual application and we are planning to implement a software reset using a command over the uart communication, thus reactivating the bootloader.
Having the bootloader entering the DFU mode by a uart command is not part of the SDK and I have been forced to make adjustments to the nrf_bootloader.c to accomplish this. I am using the app_uart/app_uart_fifo solution from the uart example and it works perfectly. The bootloader enters DFU mode if a certain command is received and the download of the application works fine which is good. Since application download is also carried out through the uart I have called app_uart_close before entering DFU mode (it simply does not work otherwise - hardly surprising).
All this is as I said fine but there is one slight problem that I need assistance with:
To test the system I have enhanced the uart example for PCA10056 (examples\peripheral\uart\pca10056\blank\ses) to work with our custom board. It works perfetly well on it's own. I have also altered the linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x100000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x40000;FLASH_START=0x1000;FLASH_SIZE=0xFF000;RAM_START=0x20000000;RAM_SIZE=0x40000"
which is a wild guess based on other examples for DFU but it works except for one thing.
The application hangs if any app_uart_ command (app_uart_put/app_uart_get) is called. Initiation appears to be successful but apart from that things get dirty. Issuing an app_uart_put command actually causes the byte to be transferred (I can receive it in the terminal program) but the application hangs.
Why does this happen? Is there something else I need to do in the bootloader or is there someting wrong with the flash memory setup that can explain this?
And most importantly - how can I solve this?
Best regards
Anders
