Encoding version in OTA binary image

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

In my application in SDK 1.x, I implemented a 'version stamp' in the OTA image that I could check for to verify the version of the image.

I implemented this by declaring a constant structure in the code that contained a version number set from #define constants in the code.

This way, I was able to search the binary image for a particular string pattern and then pull the version out.

However, when I switched over to SDK 2.x, I found that this method no longer works.

It appears that string data in SDK 2.x, when it appears in the OTA image, has other bytes interspersed

For example, in the code, there is a line like this:

  ble_trace0("===SELF TEST REPORT===");

This shows up in the OTA binary, but not in a completely obvious way:

00004020  fb f1 53 45 4c 46 20 ff  54 45 53 54 20 52 45 50  |..SELF .TEST REP|

00004030  e7 4f 52 54 fd f1 ee f0  53 49 4f ff 4e 3a 25 73  |.ORT....SIO.N:%s|

I am not sure what is going on here, but it seems clear that it won't be easy to necessarily spot a string in the OTA binary.

Is there any better way to do this?  Is there some way I can force a particular string into the OTA binary from within the SDK build environment?  I feel more comfortable having the source code automatically produce an identifying mark in this way.

0 Likes
1 Solution

I do not think it is a good idea to search for a string in a binary image.  You rely on the compiler and make process behavior which is not documented and can change any time.  If you really want a string to be a part of your image you can modify the build process to concatenate string with your binary file, store in addition or instead of the the .ota image and use that file for download.  (see top level makefile for details).  If you look through the WICED-Secure-Over-the-Air-Firmware-Upgrade.pdf in the Doc directory, you will notice that the object which is used for upgrade includes the Product ID, Major version, Minor version combined with the binary image and the signature.  Current process validates IDs and signature on the device before image is stored or made active.  But you can modify process to verify this information before performing download as well.  All source code is included, so hopefully changing it will not cause much trouble.

View solution in original post

5 Replies
ShawnA_01
Employee
Employee
10 questions asked 5 comments on KBA First comment on KBA

Do you need the root cause, or are you trying to identify a usable work-around that is consistent between SDK releases?

One thing you might want to try is:

char *SelfTestReportStr  =  "===SELF TEST REPORT===";

Then, later use it as such:

ble_trace0( SelfTestReportStr  );

You could move the declaration around to see if the results change?  ie locally in the function where it is used, or perhaps move it to being a Global variable.   Does a 'const' decoration help in any way?

I think I found a workaround, but I wanted to understand whether or not it will really work all the time.

My workaround is to create a string that is different enough from every other string that parts of it won't end up in the wrong place.

But without understanding more about what the SDK is doing to the strings, it's hard to say whether this solution will work longer-term.

You could move the declaration around to see if the results change?  ie locally in the function where it is used, or perhaps move it to being a Global variable.   Does a 'const' decoration help in any way?

It is already a global variable, and already 'const'.  It's possible that making it not const would prevent this -- i can try it. String initializers are considered const by the compiler I think, and i don't know whether or not that is also true of other initializers.  For this to work I need to see the initializer itself -- since i am scanning the binary image to find it.

0 Likes

Looking into the build process in more detail, it appears that the "compression" is occurring when it converts the .ELF format file to .CCGS files.

Is there any documentation available that describes the compression method used in producing a .CCGS file?

Alternatively, is there a way to disable this compression?  I assume all this does is save you some space in transmitting the image, which is not of great importance to me -- I assume that when the firmware is running the strings must be uncompressed in RAM.

0 Likes

Lower in the thread, I discovered that the compression is happening during the process of converting from ELF format to CCGS files.  This process applies to all of the segments of the image (text, data, and rodata), so it makes no difference how the variable is declared or initialized.

0 Likes

I do not think it is a good idea to search for a string in a binary image.  You rely on the compiler and make process behavior which is not documented and can change any time.  If you really want a string to be a part of your image you can modify the build process to concatenate string with your binary file, store in addition or instead of the the .ota image and use that file for download.  (see top level makefile for details).  If you look through the WICED-Secure-Over-the-Air-Firmware-Upgrade.pdf in the Doc directory, you will notice that the object which is used for upgrade includes the Product ID, Major version, Minor version combined with the binary image and the signature.  Current process validates IDs and signature on the device before image is stored or made active.  But you can modify process to verify this information before performing download as well.  All source code is included, so hopefully changing it will not cause much trouble.