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.

[AndersLundqvist]

Considering the fact that the original code for the uart example is (excerpt):

while (app_uart_put(cr) != NRF_SUCCESS);
while (app_uart_get(&cr) != NRF_SUCCESS);

I can only pity your example coder/designer...

And yes, I am quite certain that the led is not toggled. I am currently running the example without any call to app_uart_put and the led is blinking steadily at the desired frequency.

Debugging the application without the bootloader is pointless, since the application then runs exactly as expected.

I finally managed to get debugging while using the bootloader working. Tricky, very tricky... Should really be documentet somewhere.

I stepped the code and the PC was last seen at line 310 in nrfx_uarte.c (a fairly uninteresting piece of code). Pausing the debugger results in a helt in an "Unknown function at 0x00000686" or thereabouts which clearly is something outside the application (according to the documentation this should be in the MBR).

Is this a BUG in the SDK? A BUG in the SES? Or...?

Best regards

Anders

[Einar Thorsrud]

AndersLundqvist said:

Debugging the application without the bootloader is pointless, since the application then runs exactly as expected.

I fail to see why. The presence of the bootloader should not have any effect on the application whatsoever. So if it makes debugging more difficult, just skip the bootloader until you have found the issue, then introduce it again.

AndersLundqvist said:

I stepped the code and the PC was last seen at line 310 in nrfx_uarte.c (a fairly uninteresting piece of code). Pausing the debugger results in a helt in an "Unknown function at 0x00000686" or thereabouts which clearly is something outside the application (according to the documentation this should be in the MBR).

 That's odd. Have you built without optimization (selected Debug in the dropdown in SES)?

AndersLundqvist said:

Is this a BUG in the SDK? A BUG in the SES? Or...?

 There is not enough information here to draw any conclusion at this point. More debugging needed