Announcements
IMPORTANT: Cypress Developer Community currently doesn’t allow sign-in to prepare for the upcoming transition. To learn more, check out our announcement.
cancel
Showing results for 
Search instead for 
Did you mean: 

Smart Bluetooth

legic_1490776
Contributor II

I have noticed that when using the SDK 2.x to load firmware onto a 20736, chipload is passed the options:

-CHECKCRC and -NOVERIFY

As I understand this, this means it does a CRC check on something (not sure what) but does not do a full readback to verify the load.

What are the recommended options for use in a production / factory environment?

It seems like doing the full verification would be more conservative but slower.

However perhaps the CRC is generally adequate.

How does the CRC process work?  Does the chip compute the CRC after reading the data back out of EEPROM?

If that's the case, it seems like CRC would be sufficient. 


If the CRC was only checking what was received over UART then I might prefer verify instead, so that the actual data on EEPROM is checked.

0 Likes
1 Solution
ArvindS_76
Employee

Yes, it reads back from NV, calculates CRC and returns it to chipload which then compares the CRC to the expected CRC. If there is a mismatch, then the downloaded FW will not be marked as good.    

View solution in original post

5 Replies
MichaelF_56
Moderator
Moderator

We will check with the developers and get back to you.

santol

0 Likes
ArvindS_76
Employee

Including -NOVERIFY will disable reading back everything back from the NV before the commit. So yes, without the -NOVERIFY switch, the full verification process is slower because every section that was written to the NV is read back and sent over the UART to chipload.exe.

-CHECKCRC forces the minidriver (which does the actual write to NV) to calculate the CRC32 of all sections that were written and return this to chipload.exe, which will check it against the CRC32 it calculated.

Verifying with CHECKCRC is fast and should be sufficient. You can always remove the -CHECKCRC and -NOVERIFY parameters in the factory to force a full read-back verification instead if you need.

legic_1490776
Contributor II
-CHECKCRC forces the minidriver (which does the actual write to NV) to calculate the CRC32 of all sections that were written and return this to chipload.exe, which will check it against the CRC32 it calculated.

Just to be clear - in this case the minidriver reads back data from the eeprom to verify the CRC?

If that is the case then I agree, this will be sufficient.

0 Likes
ArvindS_76
Employee

Yes, it reads back from NV, calculates CRC and returns it to chipload which then compares the CRC to the expected CRC. If there is a mismatch, then the downloaded FW will not be marked as good.    

View solution in original post

legic_1490776
Contributor II

THanks - that was exactly what i wanted to hear

0 Likes