• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 1724 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Hercules RM48L952ZWT CRC16 Check on data stored on FEE Bank 7

Tammy Noergaard
Genius 3665 points

Other Parts Discussed in Thread: HALCOGEN

Hello. We are using the HalCoGen RM48L952ZWT. We also integrated your FEE drivers for using Bank 7 of Flash for storing data. Are there any CRC functions available in any of the HalCoGen for FEE libraries that we can use to calculate and store, so when we read it out later we can verify the integrity of our data going in and out of FEE? Thank You Again.

  • 0
    TI__Guru 69070 points

    Hi Tammy,

    There is an option to compute a CRC and store it in each block.
    But I can't tell if this is checked when reading the block - need to look at the code.


    From the doc, it looks like it is mainly checked when writing but I don't see why you couldn't just extend this to reads in the worst case.

  • 0 in reply to Anthony F. Seely
    Genius 3665 points

    Hi Anthony,  Thank you. Which document did you find this, is it the FEE document for Flash Bank 7?  Thank You Again.

  • 0 in reply to Tammy Noergaard
    TI__Guru 69070 points

    Hi Tammy,

    It's in the TI FEE User's Guide - which is packaged with HalCoGen in the <install>\HALCoGen\<version>\Docs  folder.

  • 0 in reply to Anthony F. Seely
    Genius 3665 points
    Hi Anthony. Thank you.

    Q1. I found the user guide now. In HalCoGen, under the FEE tab I did find by default CRC (Cyclic Redundancy Check) is selected. Looking at page 33 (your 4.7.15 enable crc screen shot), do we have to do "more" to enable CRC beyond what is checked in HalCoGen? Or should this already be the case because of our HalCoGen setting?

    Q2. I saw your 2nd screenshot also. But is there an example of how to use the FEE CRC to check the integrity of the data on that block of EEPROM? I did not see a section, only that generally there is a CRC. i.e., in HalCoGen it is set up that there are 4 virtual sectors that Bank 7 is divided into 1,2,3,4 according to each of the flash sectors in Bank 7) and a separate tab where in the FEE there are 16 blocks (I assume each sector has been divided into 16 blocks?) . So i.e., there would be 16 CRCs for each sector is how we should interpret that? And where are the CRCs for each of these blocks actually located, so we can read their values?

    Q3. How would getting a CRC value after EEPROM write to a particular block confirm the integrity of data of what we just wrote unless we have another CRC to compare it with for that same data? Do we need to run all the data on that EEPROM block through another CRC routine and compare it with the CRC that is stored on that block? Or is this automatic somehow?

    Thank you again.
  • 0 in reply to Tammy Noergaard
    TI__Guru 69070 points
    Hi Tammy,

    I have the same / similar questions - I asked Vishwanath to comment.
    Hopefully just some gaps in the documentation.
  • 0 in reply to Anthony F. Seely
    TI__Mastermind 19485 points
    Hi Tammy,

    My answers below:

    1. Enabling CRC in HALCoGen is enough to calculate CRC by FEE driver. Calcuated CRC is stored as part of a block header.

    2. As of now, CRC if enabled, is only used during writing of the data. If application is requesting data to be written to a block which is already
    written to FEE bank, FEE will calculate the CRC of the new data and check it against the CRC already available in block header of the block. If
    CRC matches, new data will not be written to FEE bank.
    If CRC is not enabled, comparison is done byte by byte, and FEE will write if the new data is not matching with the data in FEE bank.
    A sector can have any number of blocks. Because of GUI limitations, HALCoGen limits the number of blocks to 16. Please see section "4.7.2
    Number of Blocks"
    CRC of a block is stored as part of the block header. As of now, FEE driver does not provide API for reading of the CRC by upper layers.

    3. See answers in 2.
  • 0 in reply to Vishwanath Reddy
    Genius 3665 points

    Hi Vishwanath. Thank you for your reply. So is the CRC only for the purpose of determining of there is a change in the data and to write the changes to EEPROM, but not from checking the data integrity? Can we use this CRC FEE to actually check the integrity of the data in the FEE to make sure there is no corruption in any way? i.e., can we write to FEE, read it back, write the exact data "again" and if it is not the same -- the FEE CRC can let us know by doing the comparison and trigger a notification?  Thank you again.

  • 0 in reply to Tammy Noergaard
    TI__Mastermind 19485 points

    Hi Tammy,

    As of now, CRC is only used for the purpose of determining if there is a change in the data and to write the new data to EEPROM, but not for checking the data integrity. As of now, there is no API support to read the CRC of a block. Your request is a good use case and we would raise an enhancement request. I will let you know once ticket is available.

  • 0 in reply to Vishwanath Reddy
    Genius 3665 points

    Hi Vishwanath. Thank you. Do you have a crc software function that you recommend we use, we can integrate into FEE driver?  Thank you again.

  • 0 in reply to Anthony F. Seely
    Genius 3665 points
    Hi Anthony. Did you see below from Vishwanath? We have a deadline to release software in a week, and even a software CRC function will be Ok until TI can enhance the CRC feature. Do you have a crc software function that you recommend we use, we can integrate into FEE driver manually? Thank you again.
  • 0 in reply to Tammy Noergaard
    TI__Guru 69070 points
    Tammy,

    The function that is being used to compute the "CRC" is TI_FeeInternal_Fletcher16 from file 'ti_fee_util.c'.
    This isn't actually a CRC algorithm though. Googled 'Fletcher Checksum' it and hit a wikipedia article that says it 'approaches' CRC.
    Although I guess that needs some judgement.

    It would probably be possible for you to add a check for this directly into the fee sources - in the ti_fee_read.c or the ti_fee_readSync.c functions whichever you use.

    There is a 'real' CRC function embedded in the bootloader project from QJ - if you prefer to use that function instead.
    See 'bl_ymodem.c' in SPNA182 for example.

    -Anthony
  • 0 in reply to Anthony F. Seely
    TI__Guru 69070 points
    Enhancement Request is SDOCM00121738
    Ticket on CRC not actually implemented [checksum instead] is SDOCM00121739