• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 613 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.

TMS320F28027: Boot ROM Checksum

Sam Chen79
Intellectual 390 points

Part Number: TMS320F28027

Hi,

I need to calculate the Boot ROM checksum for the TMS320F28027.

According to the TMS320x2802x Piccolo Boot ROM Reference Guide, taking a 64-bit summation of all addresses within the ROM, except for the checksum locations, generates this checksum.

To calculate the checksum, I followed the checksum.c example below on a similar processor which calculates the same blocks:

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/185956

The blocks are:

MEMORY_BLOCK memblock[NUMBLOCKS] = {
(ui16 *)0x003FE000, (ui16 *)0x003FFFBB,
(ui16 *)0x003FFFC0, (ui16 *)0x003FFFFF
};

Inside the block in the algorithm, these calculations were used:

lowHalfLSW += *currentVal ^ ((unsigned long)currentVal & 0x0000FFFF);

and

lowHalfMSW += *currentVal ^ ((unsigned long)currentVal & 0x0000FFFF);

However, I got incorrect checksum. Could it be possible that the checksum algorithm for the 28027 is different within the blocks? What would be the correct algorithm?

Thank you.

  • 0
    TI__Mastermind 30255 points
    Sam

    The algorithm provided at the link is correct, that is what was used to calculate the checksum.
    The checksum was updated in v3.0 of the boot ROM, update your file with the following and see if that fixes it.

    #define NUMBLOCKS 3

    MEMORY_BLOCK memblock[NUMBLOCKS] = {
    (ui16 *)0x003FC000, (ui16 *)0x003FDFFF,
    (ui16 *)0x003FE000, (ui16 *)0x003FFFBB,
    (ui16 *)0x003FFFC0, (ui16 *)0x003FFFFF
    };

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Intellectual 390 points
    Hi Chris,

    Thank you for the response.

    I'm still not able to get it to work.

    The calculated checksum did change by updating the blocks (The checksum I got is now 0x0000,163F,C8CB,D21E), which is still different than the 0x0000,10BE,F62A,0B1D read at CHECKSUM_ADDR 0x003FFFBC.

    The 28027 silicon revision is B.
    Does v3.0 of the boot ROM include part of the reserved memory?

    Best Regards,
    Sam
  • 0 in reply to Sam Chen79
    TI__Mastermind 30255 points
    Sam

    Yes, that is what it looks like.
    The code owner is currently out of the office, so I'm still investigating this.

    Best regards
    Chris
  • 0 in reply to Sam Chen79
    TI__Mastermind 30255 points
    Sam

    Unfortunately, for the revB and the boot ROM v3.0, the checksum we calculated did make use of reserved memory (some internal data) that was checked as part of the calculation. From your end, you won't be able to run calculation on this data. I'm going to have an errata issued for this and documentation updated.

    Why do you need to verify the checksum? If you are checking to determine which silicon you are using, you could use the boot ROM version and date to check this. I will state that this is a stable device at this point, so a silicon or boot code change is very unlikely. Another option is, since you have the exact checksum algorithm that we used, calculate the checksum as per the 2 memory blocks from your initial post in this thread and store that value in flash to check against.

    Again, I do apologize for this inconvenience.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Intellectual 390 points
    Hi Chris,

    Thank you for the reply.

    Verifying the checksum was intended to serve as part of our data integrity test. We will use the second option you suggested for calculating the checksum.

    Best Regards,
    Sam