Over The AIr (OTA) Issues - Error 150; Update-end command; IAR workspace settings re IPD End Device - OTA Client - Initial OTA Image

It seems that these issues are unpopular, and/or no one else has really tried to do OTA with SE, and/or I was ignorant about a few IAR settings!

So, after much constructive fiddling and difficulty I have found the solutions to the issues above, so I thought I'd share them, one "reply" per issue for neatness. (and to score a few more points after all the work!)  ...

First Issue: Error 150 after a complete SE OTA process.

This seems to be triggered by the Certicom certificates as provided for the OTA example code. The location of this Certicom certificate is in $PROJ_DIR$\..\Source\OTA Cert\cert.txt. When this file is examined, the IEEE address is fixed at 00124B0000000003, and does not match the device that is being updated, and so the checking process fails producing this error 150.

The way I got around this was to disable the use of these Certicom certificates. All I did was disable the compile option named "OTA_MMO_SIGN=TRUE". This had to be done on all devices where it was set.

The drawback here then, is that the devices cannot be true SE compliant, as this requires the use of the certificates. For our project we are simply using SE as a base and are not aiming for compliance. If someone is needing compliance, I would think that the solution is to enable this compile option only once Certicom issues all the certificates to you, and then each device would have to be pointed to its particular assigned certificate containing its particular IEEE address.

Second Issue: The update end command.

This issue only seems to occur when error 150 is given back for a failed OTA process. Once the OTA process completes without any errors, the server sends the update-end command. If the client still continues to send unnecessary packets, it will only last a few seconds before it restarts itself. Perhaps a better solution would be to dive in to the server/client code, which seems to be quite comprehendable, look for the bit that sends/receives error 150, and fix it properly.

Third Issue: Differences between IAR settings for initial image and normal image.

I am wary about making a new project subcategory in our project, like what is done in the example code to use initial image or normal image, because our project has become quite complex and I didn't want to break it! Perhaps I should not be so cautious? ( Comments welcome! ) So I had to change these settings each time to switch between the two image outcomes for the same project. Its not too tedious:

The initial image must have the compile flag "OTA_INITIAL_IMAGE" enabled; Comparatively, the normal image must have this disabled.

The initial image needs the bootloader settings as described on page 18 of document SWRA353 v1.2 (2010-2013), p18; Comparatively, the normal image must NOT have this setup under the same "Linker" section.

The normal image needs to have the build actions setup as per p24; Comparatively, the initial image does not need this setup.

Other tips that were discovered:

1. The 32-bit version number of the NEW image to be sent OTA, must be a higher numerical value than that of the image presently running on the client. Else it will return error 152, indicating this problem. This issue does not seem to be mentioned anywhere in the document.

2. In the document under the section named "Adding client Functionality to an Application" (Ch4), a few essential steps have been left out!
2.1. In the subsection "Adding OTA Client Source Code", the file "hal_ota.c" also needs to be added.
2.2. In the subsection "Add OTA\Source to the Include Directories", the entry "$PROJ_DIR$\..\..\..\..\..\Components\osal\mcu\cc2538", must also be added.
2.3. In the subsection "Adding Conditional Compile Time Configuration", the compile flag "HAL_IMG_AREA=0" or "HAL_IMG_AREA=1" must be added.
2.4. In the subsection "Add OSAL Initialize and Task functions for the OTA Task", the includes "#include "zcl_ota.h"" and "#include"OTA_Dongle.h"" need to be added to OSAL_<app>.c
2.5. Under "Project" -> "Options" -> "Output Converter", the box "Generate additional output" needs to be ticked, "Output format" set to "binary", "Override default" ticked, and" <app_name>.bin" entered into the box.

3. The OtaServer from the Home Automation OTA example code, is better to use than that from SE, as it is a newer version.

4. If one wants to use the dongle code to add OTA server functionality to one'sdevice, all the related .c files can simply be added as extra end-points, with appropriate changes, to the OSAL_<app>.c file. I am busy with this and have not tested this completely, but it does seem to work.

But one problem remains!! -

Our Coordinator has USB enabled within its Z-Stack, and I have successfully added the OTA-server files as extra end-points. My app uses the UART and so does the OTA-server code, and there doesn't seem to be a problem there.

However, when I attempt an OTA sequence, its start ok but then every ~5 seconds, it pauses for no apparent reason for about another 5 seconds, then continues to send/receive the block-responses, then pauses again, etc. This wouldn't bother me, but at some point the process simply stops and the client is unresponsive, to the point that I have to completely reprogram it with the initial image.

I added the USB functionality to the dongle example code (OTA-server code), and it has the same behavior! So it seems that the USB system is conflicting the the OTA system.

Any suggestions??

Thanks so much for your time.

I have experiences using OTA in Z-Stack Home with CC2530. You can try to send a private message to TheDarkSide or JasonB to see if they can help you.

Ok thanks YiKai, I'll do that.

You are welcome and good luck.