Problems with uart in both bootloader and application

RE: Problems with uart in both bootloader and application

AndersLundqvist — Mon, 01 Oct 2018 13:32:30 GMT

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

RE: Problems with uart in both bootloader and application

Einar Thorsrud — Mon, 01 Oct 2018 13:00:47 GMT

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

RE: Problems with uart in both bootloader and application

AndersLundqvist — Thu, 27 Sep 2018 09:04:24 GMT

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

RE: Problems with uart in both bootloader and application

AndersLundqvist — Thu, 27 Sep 2018 08:24:55 GMT

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

RE: Problems with uart in both bootloader and application

Einar Thorsrud — Thu, 27 Sep 2018 06:20:17 GMT

Hi Anders,

[quote user="AndersLundqvist"]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 [/quote]

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.

[quote user="AndersLundqvist"]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].[/quote]

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.

[quote user="AndersLundqvist"]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).[/quote]

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.

[quote user="AndersLundqvist"]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. [/quote]

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.

[quote user="AndersLundqvist"]Data already loaded into RAM does not magically disappear when changing PC to a different location (app), or...?[/quote]

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.)

RE: Problems with uart in both bootloader and application

AndersLundqvist — Wed, 26 Sep 2018 14:00:37 GMT

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 (no code in the real world is flawless). :-)

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].

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).

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. Data already loaded into RAM does not magically disappear when changing PC to a different location (app), or...? Not speaking of alterations to hardware registers done using the bootloader... Are you implying that you can load an address into the processor memory and then wipe the entire processor blank (except for the adress mentioned) before a reboot and that the processor sees this after the reboot and continues execution from the adress pointed out? Nice feature but is that really the case?

Best regards

Anders

RE: Problems with uart in both bootloader and application

Einar Thorsrud — Wed, 26 Sep 2018 13:37:55 GMT

[quote user="AndersLundqvist"]Debugging the application without the bootloader is pointless, since the application then runs exactly as expected.[/quote]

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.

[quote user="AndersLundqvist"]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).[/quote]

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

[quote user="AndersLundqvist"]Is this a BUG in the SDK? A BUG in the SES? Or...?[/quote]

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

RE: Problems with uart in both bootloader and application

AndersLundqvist — Wed, 26 Sep 2018 13:29:15 GMT

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

RE: Problems with uart in both bootloader and application

Einar Thorsrud — Wed, 26 Sep 2018 12:41:58 GMT

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.

RE: Problems with uart in both bootloader and application

AndersLundqvist — Wed, 26 Sep 2018 12:16:21 GMT

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

RE: Problems with uart in both bootloader and application

Einar Thorsrud — Wed, 26 Sep 2018 12:04:17 GMT

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).