CC2540: Bank A CRC mismatch for CC2540 devices with OAD running BLE Stack 1.4.0

Hi,

Title: Bank A CRC Mismatch for CC2540 devices with OAD running BLE Stack 1.4.0

Background

In our system, the BLE device has one serial port UART operating at 115,200 baud that is used as the management port by the host device.  The second serial UART operating at 9600 baud for a different application.

The TI BLE Stack version is 1.4.0.

On our CC2540 the flash is asymmetric with Bank A occupying 88 KB and Bank B at 160 KB. The physical partitioning of the flash is as follows:

Bank_B contains the production image, while the sole purpose of the image in Bank A is to upgrade Bank B.  To upgrade Bank B, we first switchover to Bank A, upgrade Bank B and then switchover to Bank B.

Our system also provides the ability to upgrade Bank A too when running out of Bank B, but this feature is meant to be seldom used.

All upgrades take place using TI provided OAD design, either over-the-air or over the serial port. 

This is a rehash of how the BIM (TI's boot loader) and OAD works:  The header of each image contains a 2-byte primary CRC that is computed during compilation and inserted into the header, while the next two bytes, the shadow CRC, is left alone with a default initializer of 0xFFFF (since it's in Flash). 

On boot-up, BIM first attempts to boot out of Bank_B by comparing the primary CRC and the shadow CRC for Bank_B.  If the shadow CRC is 0xFFFF, BIM computes the actual CRC for the Bank B image, compares it to the primary CRC in the header of Bank B image and if the two match, writes out the CRC to the shadow CRC for Bank_B, and resets the device. If on the other hand the primary CRC and the computed CRC do not match, BIM conducts the same sequence for Bank A. 

Since upgrading to Bank B requires a switchover to Bank A, the switchover request first checks if the primary CRC and shadow CRC match.  If so, a switchover occurs.   If they do not match, and the shadow CRC is 0xFFFF (implying we have never executed out of Bank A), we first compute the CRC for the Bank_A image, write it out to shadow CRC and if the two match, we switchover to Bank A.  This ensures we never brick our system since the switchover to Bank A involves invalidating Bank B as per TI's OAD design rules.

One other point worth noting: When the device boots out of Bank A or Bank B, the TI BLE Stack, provided in binary only, writes, what we were informed is "calibration data", in the middle of the bank.  The one serious consequence of this is that the CRC of the image after this "write of calibration data" has occurred results in the computed CRC of bank never matching the primary CRC ever again or at least until the bank is upgraded.

Problem Statement

We implemented a system where upgrades take place over the serial port and sometimes using OAD. On 60% of the BLE devices in our scale testbed, there were no issues.  On around 40% of the devices, we found that the Bank_A primary CRC and shadow CRC did not match.

How did the system ever get into this situation?

It turns out the shadow CRC contained the value, as if the CRC was computed after the “calibration data” had been written out.  But, the way TI Stack works, the calibration data can only be written out to the corresponding bank, if the device booted out of the bank.

But, in this case, we have a situation where the calibration data was written out to Bank A implying we executed out of Bank A, but the primary CRC does not match shadow CRC, so we could never have executed out of Bank A.

We are not sure how to explain this paradox.  TI's help is appreciated in resolving this problem.

Regards,
KK