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.
I repeat this many times for different instructions and it works when the build configuration is DEBUG.
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.
There *may* be a gnu linker (ld) relocation issue.
Some time ago, I was developing a bootloader application (which was fine).
loader itself in the flash.
Then I noticed that some (constant) strings were not being accessed correctly.
related to the size of another section that I had created to effect the copy from flash to ram.
involving the text section array with offsets to rodata strings was affected.
This may all be totally irrelevant, but the 'selectivity' of the wandering strings ran a bell with me.
interrested in any confirmation and/or resolution, so please post back any results that arise.
Using this link I was able to debug through the boot loader.
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.
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.
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.
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.