SIMPLELINK-CC13XX-CC26XX-SDK: CRC check fails on Bim_revertFactoryImage

Hi Matthias,

Most of our experts are out of the office due to Thanksgiving holiday. Please expect some delays in our responses.

Thank you for the detailed explanation you have provided.

May I ask if you have tested the same with a different SDK version?

Looking into the code, I see a difference in the way the parameters passed to the CRC32_calc() function are computed. It could be interesting to identify if the function ends up being executed with different parameters values in the two cases. 

Best regards,

Hi Clément,

thank you for your first reply!

I have the same behaviour with an application based on stack 5.10, so I tested it on a clean simple peripheral and bim project based on stack 5.30.

So the answer is yes: on stack 5.10 and 5.30 the problem exists.

Matthias 

Hi,

Ok, thank you. This removes the possibility/need to review the changes introduced between these SDKs versions.

If you have an easy way to run the test I have suggested - i.e. compare the parameters used by CRC32_calc() across its executions - it would help to confirm if we are heading in the right direction.

Best regards,

Here the test results of the different CRC32_calc() executions:

Steps:

1. Flash hex => crcStat = CRC_VALID
2. Run BIM unmodified: only check of crcStat, no crc calculation
3. oadCreateFactoryImageBackup => copy internal image to factory image
4. Run BIM:
   1. checkImagesIntFlash (internal image = flashed image)
      1. modified: force check crc; do not change crcStat
      2. Crc check failed: uint32_t crc32 = CRC32_calc(flashPageNum, intFlashPageSize, 0, imgHdr.len, false);
      3. flashPageNum = 0
      4. intFlashPageSize = 8192
      5. imgHdr.len = 125828
      6. crc32 = 115578173
      7. imgHdr.crc32 = 860944785
   2. Bim_revertFactoryImage (after checkImagesIntFlash  failed)
      1. Bim_copyImage
      2. Crc check failed: uint32_t crc32 = CRC32_calc(FLASH_PAGE(startAddr), intFlashPageSize, 0, metadataHdr.fixedHdr.len, false);
      3. startAddr = 0
      4. intFlashPageSize = 8192
      5. metadataHdr.fixedHdr.len = 125827
      6. crc32 = 1514820252
      7. metadataHdr.fixedHdr.crc32 = 1096856370
5. Run BIM again
   1. checkImagesIntFlash (internal image = reverted factory image)
      1. Crc check failed: uint32_t crc32 = CRC32_calc(flashPageNum, intFlashPageSize, 0, imgHdr.len, false);
      2. flashPageNum = 0
      3. intFlashPageSize = 8192
      4. imgHdr.len = 125828
      5. crc32 = 3894070137
      6. imgHdr.crc32 = 860944785
6. OAD with ti_oad_example app (modified: prevent reset) => oad image = flashed image
7. BIM:
   1. checkImagesExtFlash:
      1. Bim_copyImage
      2. Crc check succeeded: uint32_t crc32 = CRC32_calc(FLASH_PAGE(startAddr), intFlashPageSize, 0, imgFxdHdr.len, false);
      3. startAddr = 0
      4. intFlashPageSize = 8192
      5. imgFxdHdr.len = 125828
      6. crc32 = 860944785
      7. imgFxdHdr.crc32 = 860944785
   2. checkImagesIntFlash ((internal image = oad image)
      1. Crc check failed: uint32_t crc32 = CRC32_calc(flashPageNum, intFlashPageSize, 0, imgHdr.len, false);
      2. flashPageNum = 0
      3. intFlashPageSize = 8192
      4. imgHdr.len = 125828
      5. crc32 = 115578173
      6. imgHdr.crc32 = 860944785

Short summary:

- flashed image = factory image = oad image

- Bim_revertFactoryImage has reduced hdr.len

- crc check fails for intial flashed image => crc check buggy or flashed image creation with oad_image_tool might be not correct?

- crc check succeeds for checkImagesExtFlash => image (oad image = flashed image) creation with oad_image_tool might be correct!?

- next crc check of internal image after oad (checkImagesExtFlash) fails but it should be the identical image and CRC32_calc is called with identical parameter!? 

I hope this helps!

Hi Matthias,

Thank you for the details. I have to tell you I am a bit confused by the results.

Any chance you could run the same tests on a different launchpad? Even if pretty unlikely, I would like to completely eliminate the possibility of an hardware issue. 

I have also taken a few notes while looking at your results, maybe it could give an idea:

• a) We are comparing the CRC against the initial CRC è is CRC properly updated on the image
• b) Not sure what we have copied + could the crc be completely off because of an error in the image header length?
• 5) How have you forced reverting to the factory image? If you are using the function markSwitchFactoryImg(), this will invalidate the image by changing crcStat. Any chance it could affect the CRC calculation?
• a) Great to see the CRC is correct. It probably means the CRC32_calc works. Maybe something is off when calculating CRC on the internal flash?
• b) The CRC value is identical as what we had at first. Any chance we have a bit stuck? Any chance we are considering the wrong area to run the CRC check?

Best regards,

Yes indeed, it is confusing..

I havent got another launchpad at the moment but I have the same issue on our production modules based on CC2642. So I am convinced that the issue is not hardware affected.

Clément said:

a) We are comparing the CRC against the initial CRC è is CRC properly updated on the image

Seems to be. Or the crc is calculated from the wrong length or flash location

Clément said:

b) Not sure what we have copied + could the crc be completely off because of an error in the image header length?

As I understand the factory image of external flash is copied to internal flash. It should be identical to flashed image. So the crc should be the same as in 4a).

Another point: It seems, that the image header of factory image is not the image header that has been flashed initially. I would expect that it must be the same, because of running oadCreateFactoryImageBackup before. Maybe this is an issue and the reason for the different header length?

Clément said:

5) How have you forced reverting to the factory image? If you are using the function markSwitchFactoryImg(), this will invalidate the image by changing crcStat. Any chance it could affect the CRC calculation?

I faked the bim in 4a) by returning checkImagesIntFlash after crc_calc and skipping change of crcStat. So it runs Bim_revertFactoryImage with unmodified image header.

Otherwise: changing the crcStat in image header should not change the crc calculation.

Clément said:

• a) Great to see the CRC is correct. It probably means the CRC32_calc works. Maybe something is off when calculating CRC on the internal flash?
• b) The CRC value is identical as what we had at first. Any chance we have a bit stuck? Any chance we are considering the wrong area to run the CRC check?

The crc is calulated on internal flash after Bim_copyImage (a) with the same parameters as later on checkImagesIntFlash (b). So I assume that it is the same area. 

Hi Matthias,

Please allow me a couple of days to consult our experts. I think I have missed something here and additional eyes should help.

Keep me updated if you make new observations/experiments.

Thank you for your patience.

Best regards,

Hi Matthias,

Thank you for your patience.

When testing OAD, we would highly suggest that the external flash be erased before performing any tests/expirements. I've seen weird results if there is old images or junk in the ext flash. To erase the external flash, I've usually just used <sdk>\examples\rtos\CC26X2R1_LAUNCHXL\easylink\hexfiles\offChipOad\erase_storage_offchip_cc13x2lp.hex. This hex file should be flashed on the device using FlashProgrammer or Uniflash. It will blink the red and green leds until all external flash pages have been erased. Once it is done, the flashing will stop. At that point, the external flash is completely empty and ready to be used for consistent testing.

Second element, may I ask why you are using BTN1 as the factory image creation? When OAD_open() is called, it will automatically look for a factory image, and if it does not exist (which it will not if the external flash has been erased as mentioned above) it will create one.

Could you please test first erasing the flash, then rely on the default and automatic image creation? This would help us to narrow down the cause of the issue.

Best regards,

Hi Clément,

The erase flash hex is very helpful!

I flashed it and the external flash has been erased. Then I flashed my test application hex and started the factory revertion.

Unfortunately, the problem is still existing: calculated crc is not equal to the expected crc (check fails), so bim is not starting the image.

The reason for using the BTN1 function was an easy way for me for setting the factory image. But I agree that using the flash erase is much more comfortable. Thank you for your tip!

Hi Matthias,

Thank you for these details.

Could you please share the SysConfig configuration of the NV memory? Please also specify if you are using several NV regions or if you have modified them.

Thanks and regards,

Hi Clément,

here are the CSS screenshots of my sysconfig.

It is the default simple peripheral offchip config for the launchpad without any modifications.

If you need more datails, just let me know.

Hi Matthias,

Thank you for your patience.

With my team we have looked into a couple of elements that may explain the issue, but so far we do not have any good explanation. 

We do not manage to reproduce the issue using the out of the box example. On our end, all the CRC calculations / CRC tests pass ok.

At the moment I could suggest to verify that the CRC calculated by the script is correct and properly written in the image's header.

Best regards,

Hi,

I am about to close this thread as I will be out of the office for a few weeks.

Please open a new thread if additional support is needed.

Best regards,

Hi Clément,

I am out of office for the next weeks as well.

Maybe you can answer me the following short question before closing this thread:

I found a known issue in release notes of stack 5.30.01.01: https://sir.ext.ti.com/jira/browse/EXT_EP-9909

It seems to be the same problem. Is it planned to be fixed?

Hi Matthias,

These are excellent news, thank you.

Thank you also for your patience here.

Now we can both have relaxing holidays!

Kind regards,