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]

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]

Hi Anders,

AndersLundqvist said:

Believe me, it IS working flawlessly if no bootloader has started the application. Why? Well perhaps because the code is correct to the point where it actually executes

If that is the case then it might be that the bootloader does not clean-up properly before starting the application (e.g. some UART registers might not have their default value assumed by the UART driver in the application), but the SDK bootloader should clean-up properly. I any case I think you need to debug a bit more to see exactly what happens in your application to find this. 

AndersLundqvist said:

I have no clue as to what you are referring to. If I look into the options for the project I can see that the "Optimization Level" is set to "Optimize For Size". Compilation has (as always?) been carried out using [Build][Rebuild Solution].

Breaking and stepping through code when you optimize (particularly for size) is not easy as the resulting machine code can be quite different from the C code you are looking at. Therefor disabling optimization is always a good idea in such cases. In the SES projects we deliver in our SDK there is both a "Release" and "Debug" build configuration. Using "Debug" disables optimization (among other things) to make debugging easier. Please use that and try again.

AndersLundqvist said:

If the program counter (PC) leaves the program area it either means that someone has set a function pointer to a not so good location or it means that some memory location has been overwritten (hey it's C-code we are talking about).

I agree that it is a likely explanation. As you have such a simple application you should be able to track down where this happens using a debugger quite easily.

AndersLundqvist said:

You also say that there is no difference if the bootloader is present or not. Could you explain that in more detail to me, because I do not follow you in that respect.

You are right that the bootloader does a few things as you have described, but it should clean-up properly after itself. It might be some issue here, but in any case, I think the proper way to handle this is to debug the application a bit further to see what actually goes wrong. If the problem is that some register or similar is not as expected, then you can go back to the bootloader code and see if it can be to blame.

AndersLundqvist said:

Data already loaded into RAM does not magically disappear when changing PC to a different location (app), or...?

Of course. But if your application uses uninitialized RAM (previously used by the bootloader as you suggest or not), then that is a bug in your application. You cannot blame the bootloader for that. (I am not suggesting this necessarily is the case here, though).

So to sum up I still think you need to debug the application to see where and how things go wrong. (That does not mean that I am certain that the bootloader does not have anything to do with it.)

[AndersLundqvist]

OK.

I have tried debugging while disabling optimization in SES. The results are unclear and the stepping loses control after the app_uart_put. If I put a breakpoint on the next instruction in main it hits that breakpoint but after that it loses control. My guess is that the transmission causes an interrupt when the data has been written and that ISR (which and where?) fucks up everything. Is this your opinion as well?

I'd like to point out that, apart from very modest changes of the bootloader and the uart app, I have not written any of the code that is running. I have disabled flow control but apart from that no changes has been made to the sdk_config.

There is no point in me continuing the project until this issue is solved because we do need a working uart in our real application.

I just had a look at the secure_bootloader_uart_mbr_pca10056_debug and it has "Optimization" to "Optimize For Size". What exactly have you altered in your debug projects for SES?

Best regards

Anders

[AndersLundqvist]

Now I have tried the same setup (this time without any alterations at all in the bootloader, except FC disabling which is needed in my case) and it does not work! I have tried debugging and it works exactly like on our custom board...

Could you please verify this on your side, i.e. Compile a secure_bootloader_uart_mbr_pca10056_debug, download it to the board:

nrfjprog --eraseall
nrfjprog --program secure_bootloader_uart_mbr_pca10056_debug.hex --chiperase
nrfjprog --program mbr.hex
nrfjprog --reset

Compile the examples\peripheral\uart\pca10056\blank\ses with FLASH_START 0x1000., create a package with the same key used with the bootloader and finally program it using:

nrfutil dfu serial -pkg uart_pca10056.zip -b 115200 -p COM3 -fc 0

Does it work as expected?

Best regards

Anders

[Einar Thorsrud]

Hi Anders,

Now I see the problem. The MBR needs 8 bytes of RAM, so you have to adjust the RAM start address of your application to 0x20000008 (and reduce the RAM size by 8). This is not documented for the stand-alone MBR as far as I can see, but it is documented for the SoftDevice. (I have reported this lack of documentation internally.)

Br,

Einar

[AndersLundqvist]

Hi Einar,

It actually works! In retrospektive it was actually there in the blinky example as well. If you know where to look that could have been a giveaway but in this (and many other cases) there were quite a lot of places to look.

However, in my defence, the symptoms were very hard to analyze and the fact that the application actually worked as long as the uart was not engaged, it was far from obvious. Come to think of it, there is likely some interrupt that ends up in the MBR instead of inside an ISR.

In this project we will not use any Soft Device at all, so why should I look for information there? This should be covered in at least some DFU page.

But many thanks! I had almost given up hope on this and was starting to consider writing my own bootloader...

Best regards

Anders