TMS570LS1224: Boot Time Check of FEE Memory Contents by Hardware CRC

Hi Marcus,

If the EEPROM is preprogrammed and has fixed content, the FEE2A and FEE2B are applicable. Otherwise the FEE2A and FEE2B are not applicable. 

Hi QJ, after a closer look at your reply I think I need a little clarification:

1. I assume that your ref's to "FEE2A" & "FEE2B" are to the Unique Identifiers in Table 4 of the Safety Manual.
2. Table 4, column [Possible Tests for Diagnostics], covers more than CRC checks; just what aspect of "FEE2A" & "FEE2B" do you consider to be not applicable?
3. I'm confused that you state that both "FEE2A" & "FEE2B" are not applicable when FEE contents is not fixed; since these two IDs appear to only differ re when the checks can be done, with only "FEE2A" applying to Boot Time, surely it is only "FEE2A" that could possibly be not applicable?  The reason I say that is that my original assumption was that we would have to generate a "Golden CRC" at Boot TIme and then maintain that CRC in response to any updates to the FEE at Run Time, thus allowing a periodic check of the CRC to at least cover "FEE2B".   In fact, is it not possible to extend such cover of "FEE2A" to "FEE2B", if the Run Time re-gened  "Golden CRC" was secured in FEE, thus allowing it to be also checked at Boot Time?

Marcus

Hi Marcus,

1. Yes, you are right. They are FEE2A and FEE2B in safety manual

2. I mean the CRC calculation of FEE content.

3. If the content in EEPROM keeps changing during runtime, how and when is the "golden CRC" calculated and used? If the content is fixed, we can use the  hardcoded Golden CRC at boot time and during runtime, or we can calculate the CRC at boot time, and use this CRC as "golden CRC" to check the CRC during run time.  

The EEPROM is also protect by ECC (SECDED). The FEE driver supports check sum for FEE data block too.