Problems with uart in both bootloader and application

[AndersLundqvist]

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

[Einar Thorsrud]

Hi,

What do you mean when you say that the application "hangs"? The most common reason for seeing a unresponsive application (or an unintended reset) is that an error has been caught by an APP_ERROR_CHECK(). In that case the device will enter a eternal loop in de debug handler for debug builds (DEBUG defined) or reset for release builds (DEBUG not defined). I recommend you start by checking if that is the case (using the debugger).

[AndersLundqvist]

Hi,

The code is as follows:

uint8_t cr = 'A';
while (true)
{
app_uart_put(cr);

nrf_delay_ms(300);
nrf_gpio_pin_toggle(LED_2);

if (cr == 'q' || cr == 'Q')
{
printf(" \r\nExit!\r\n");

while (true)
{
// Do nothing.
}
}
}

If app_uart_put(cr); is executed but not the pin toggling (and supposedly the delay). I consider the code not running anymore. I see no call to APP_ERROR_CHECK() in app_uart_put(). The 'A' is received "on the other side" of the uart i.e. my terminal program.

Just curious, how do I use the debugger when the code that is running is started by the bootloader? That would indeed solve most of my problems...

Best regards

Anders

[Einar Thorsrud]

Hi,

You do not need to do anything in particular to debug when you have the bootloader (see for instance this thread). However, it is quite tedious as every time you make a change in the application you have to update the bootloader settings, if not the bootloader will not start the application. Therefore, I generally recommend to debug without the bootloader installed (you can still use the exact same application without any adjustments).

You should always check return values using APP_ERROR_CHECK() so that things does not fail silently, which you do not do for the call to app_uart_put(). It does not seem relevant in this case though. Are you sure the GPIO (LED_2) is not toggled? How have you verified? I expect you will see where the problem is quite fast when you start using the debugger.