Recommendation on use of NOVERIFY in production

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

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

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
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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

santol

0 Likes
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

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.

-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

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.    

THanks - that was exactly what i wanted to hear

0 Likes