Smart Bluetooth Forum Discussions

[legic_1490776]

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.

[MichaelF_56]

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

santol

[ArvindS_76]

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]

-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.

[ArvindS_76 · Accepted solution]

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.    

[legic_1490776]

THanks - that was exactly what i wanted to hear