CC3220SF-LAUNCHXL: ROM loader bahavoir in case of corrupt test binary file

Hi Christian,

I'll try to explains by illustrating two examples of what could happen based on whether your new image (the one you reboot into) is corrupt or not.

In case 1, where your new image is not corrupt:
If you do not commit the image immediately, you can run from it for as long as you don't reset again. If you reset the device while your mcu image is still flagged as pending commit, then the mcu image will revert back to the previous failsafe image. This means that you can take your time in figuring out whether or not the image is valid, do any tests you might want to see if it functions, before deciding to commit. The thing you have to keep in mind is that your uncommitted image will be reverted if you reset, so you can't really have two valid application binaries stored in serial flash using the failsafe image as a backup. Technically, during the one boot you have with the uncommitted image this is the case, but after that boot either both running + failsafe are the old image, or both are the new image.

In case 2, where your new image is corrupt:
This is the case you presented in your original question. In the case where you write corrupt code into the mcuflashimg.bin and then reboot while uncommitted, the bootloader will take that code and attempt to run it. If it is corrupt, you will likely end up with a hard fault, in which case the CC3220 will be stuck. This is until the next time you reset the device, since like I explained above on the next boot an uncommitted image is reverted to failsafe.

Now, while it is usually not too much of a problem to reset the device in this case by pressing a button to assert reset, or through removing power to the device, devices which cannot rely on user intervention for this failsafe reset would be effectively bricked in this case, unless the device could somehow reset itself despite having bad code.

Fortunately, self-reset capability is present in the CC3220 ROM bootloader. It is possible for the bootloader to turn on and set the hardware watchdog timer when loading an uncommitted mcu image. This hardware watchdog timer will reset the device if it is not disabled within a certain configurable time after boot. Thus, the boot flow for a corrupt image looks like this:
1. Bootloader loads uncommitted (corrupt) image. It also sets the watchdog timer.
2. Bootloader jumps to start of program and begins execution.
3. MCU crashes due to bad instruction/bus fault/etc.
4. Watchdog timer expires, triggers reset
5. Bootloader reverts uncommitted image to failsafe, loads old code into memory.
6. Old program runs

To enable this bootloader watchdog, you should look at Platform_CommitWdtConfig() in platform.c of the cloud_ota SDK example. Essentially, you write a special file that the bootloader will check at boot into the filesystem as part of your OTA process, before you reboot into the uncommitted image. With that file present, the bootloader will enable the watchdog timer whenever it boots an uncommitted image. This does not enable the watchdog timer in the case of a normal boot with a committed image.

After you reset into the uncommitted image, you will have to of course disable the watchdog timer. This is done through the Platform_CommitWdtStop() function.

I hope that clears up your questions about the watchdog timer. Feel free to ask any questions you might still have.

By the way, what made you decide not to use TI's OTA library? You mentioned some compatibility problem, but what exactly? We are looking for feedback on the OTA library.

Regards,
Michael

Hi Michael,

this actually answered my next question also, thanks.

Our customer has its own ota rollout system which uses customized communication protocol. They want us to have the new product fully compatible to this system.