RDB1768_CMSIS2_USB Bootloader

[lpcware]

Content originally posted in LPCWare by Andre Schoeman on Thu Dec 05 00:23:11 MST 2013
Hi

I'm using the CMSIS2_USB boot loader on an LPC1768.
It seemed to be working, USB download works, code runs, but recently we identified the following behaviour.

I parse messages from a Bluetooth module using the strcmp function.
For example

if(strcmp(t[0],"MYID" == 0)
{
    ...we found the string do something...
}

I repeat this many times for different instructions and it works when the build configuration is DEBUG.
When the build is for RELEASE_BIN, this creates the binary file for USB transfer some, not all, of these lines no longer work. (this file is loaded via USB and then tested.)

I have checked that the RELEASE_BIN uses alternate linker script files to move the program higher up in memory.

It's as though some string constant are omitted from the build.
I have seen the same thing with an array of constants which were not applied in a set of calculations.

I have inspected the binary file and the ("MYID") strings are in the file.
I have done a memory dump from the LPC1768 and the strings appear to be on the chip.

The general code seems to work, drive motors, maintain a Bluetooth and other serial connections.

It seems odd that only some strings and constant arrays are impacted.

Anybody have any suggestions?

Thanks
Andre

[lpcware]

Content originally posted in LPCWare by Andre Schoeman on Sat Dec 07 16:13:00 MST 2013
Hi

You are right strlen is doing what it says on the tin.
strlen is being used correctly, the pointer being passed to it has not been checked for NULL.

What started as very strange behaviour turns out to be a nothing more than a pointer to 0 (NULL) being incorrectly applied.

data at address 0 for the boot loader is not the same for the application.

As it turns out address 0 for the application contains 0, but for the boot loader it contains 2 bytes then a 0.
That is why strlen returns 2 in my explanation above.
That is why the application worked when located at 0 and did not work with the boot loader at 0.

Thanks for the replies.
Andre

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Dec 06 01:36:22 MST 2013
Why would you expect anything else? In the embedded world, there is an address at 0x0 (i.e. NULL) and it could be valid to call strlen() on it... My guess is that strlen is doing 'exactly what it says on the tin' and returning the lenght of the 'string' located at 0x0. If you want a null pointer check, you will have to do it yourself and not rely on strlen to fault it.

[lpcware]

Content originally posted in LPCWare by Andre Schoeman on Thu Dec 05 15:23:54 MST 2013
Hi

Thanks for the replies,
Using this link I was able to debug through the boot loader.

http://support.code-red-tech.com/CodeRedWiki/DebugThroughBootloader?highlight=%28BOOTLOADER%29

and was surprised to find the following.
The code as I described above appears to be there and is in fact operational.
Once I have identified the incoming command I call a function to process the command.
To this function I send one or more pointers to parameters that may have been sent with the command.

I use the strlen function to determine whether the (parameter) pointer is NULL or contains characters.

It is at this point that the strlen fails. I can see from the variables watch window that the pointer is NULL, but strlen returns a value of 2.

A serial port "debug" print confirms the invalid length returned by strlen.

I would have considered the path that the code has followed impossible, but based on what I am seeing now obviously not, and hence the reason I thought the "strings" had to be at fault.

Mike, it may be that my problems and yours are not heading in the same direction, thanks for the reply.
(But, I still need to look at why a constant array was not applied correctly.)

Any thoughts on why the strlen would fail?

I can code around the strlen function by just comparing the pointer to NULL, but in some instances the returned value is used in parameter character length checking.

Thanks
Andre

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Thu Dec 05 01:23:46 MST 2013
There *may* be a gnu linker (ld) relocation issue.

Some time ago, I was developing a bootloader application (which was fine).
Towards the end of the development I tried to arrange for the loader to relocate itself
in to the on-chip static ram (LPC1778) and run from there -- so I could update the
loader itself in the flash.

This was acheived with a custom linker script (relying on the 'AT ...' modifiers) and
indeed this seemed to work -- with the relocated code gaining control and running
quite happily in ram.

Then I noticed that some (constant) strings were not being accessed correctly.

These were in an array (e.g. char *Fruit[] = {"apple", "orange", ...} pretty basic)

The compiler put the string text in an rodata section and the actual array (of string addresses)
in a text section.

All worked fine when the loader was placed and executed from flash, but the relocated to ram
version had a constant offset error for all the string addresses in the array which seemed to be
related to the size of another section that I had created to effect the copy from flash to ram.

To be strictly fair, the custom linker script may have been at fault, but it seemed that only relocations
involving the text section array with offsets to rodata strings was affected.

As the size of the loader grew such that it was not going to fit in the on-chip ram, I abandoned
the feature for self update, and did not raise the issue with Code Red (also my support period had
expired).

I was using LPCXpresso 5.3 at the time,

This may all be totally irrelevant, but the 'selectivity' of the wandering strings ran a bell with me.
If there actually is an issue with linker relocations concerning multiple sections, I would be extreemely
interrested in any confirmation and/or resolution, so please post back any results that arise.

All the best, Mike

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Thu Dec 05 01:05:02 MST 2013
Have you read this?

http://support.code-red-tech.com/CodeRedWiki/CompilerOptimization