TMS320F280049C: TMS320F280049C Boot ROM CRC

Alberto Peyro

Part Number: TMS320F280049C
Other Parts Discussed in Thread: C2000WARE

Hello all,

I was reading document SPRUFN6–December 2008 (link provided at the end), regarding Boot Rom for F2802x devices. I was wondering if there is a similar one for TMS320F280049C. I am trying to identify Boot ROM CRC and revision values so it can be checked during application start up, it is a request from customer. Could you kindly help me out with this...

Thanks in advance for the time and best regards,

Alberto Peyro

link to file:

over 7 years ago

0 Christopher Chiarella over 7 years ago

TI__Mastermind 30255 points

Hello

Boot revision info is detailed in the TRM: www.ti.com/.../sprui33
There is a checksum available for the unsecure boot ROM region. The source code algorithm for this (as well as MAP file if you want to call the function from application) is in C2000Ware.

Best regards
Chris

0 Alberto Peyro over 6 years ago in reply to Christopher Chiarella

Intellectual 340 points

Hello Chris,

Thanks for the reply! I have checked the documentation and the code. I still have a doubt. On page 605 of technical manual, the memory map of Rom area says that there are 42 words of checksums, I imagine these are the golden values to use with the cpubrom_checksum.c algorithm that is on C2000Ware package under C:\ti\c2000\C2000Ware_1_00_04_00\libraries\boot_rom\f28004x\revB\rom_sources\F28004x_ROM\bootROM\source

But when I run the code on a test project I cannot get the expected golden values! Is my reasoning OK?

At the end I want to make sure of the crc of the area: 0x3F0000 to 0x3FFFFF that contains among other things
the TI bootloader that is executes every time the DSP get restarted.

Thanks and regards,
Alberto Peyro

0 Christopher Chiarella over 6 years ago in reply to Alberto Peyro

TI__Mastermind 30255 points

The technical reference manual table lists the wrong checksum, I'll get that corrected. We have two checksums, one is internal only. The golden 42 words for unsecure ROM check starts at 0x3FE9D0. Use that location to compare against.

Best regards
Chris

0 Alberto Peyro over 6 years ago in reply to Christopher Chiarella

Intellectual 340 points

Hello Chris, I checked the address you provided but still cannot find a match, please check at my Code Composer screen, I have the results from the TI checksum routine and the memory dump of the area you mentioned...

0 Christopher Chiarella over 6 years ago in reply to Alberto Peyro

TI__Mastermind 30255 points

I see now. The checksum in ROM indicates you are using revA silicon. You'll need to use the revA checksum.c
\libraries\boot_rom\f28004x\revA\rom_sources\F28004x_ROM\bootROM\source

Best regards
Chris

0 Alberto Peyro over 6 years ago in reply to Christopher Chiarella

Intellectual 340 points

Hello Chris, I have tested the CRC checksum for revA and it worked. Although, let me ask you if we can read from ROM any register that tells us if the silicon version is revA or B, so we can apply the proper checksum routine. Thank you
Best regards,
Alberto Peyro

0 Christopher Chiarella over 6 years ago in reply to Alberto Peyro

TI__Mastermind 30255 points

Excellent!
You can read the ROM version - revision number location in ROM. A value of 0x0100 is revA and a value of 0x0101 is revB

Best regards
Chris

0 Alberto Peyro over 6 years ago in reply to Christopher Chiarella

Intellectual 340 points

Thanks for the help Chris!

0 Alberto Peyro over 6 years ago in reply to Christopher Chiarella

Intellectual 340 points

Hello Chris,

Just wondering if you have a faster ROM CRC algorithm implementation? it is taking up to 0,5seconds to run and we are getting out some specs!

Thanks for any help!

Alberto

0 Christopher Chiarella over 6 years ago in reply to Alberto Peyro

TI__Mastermind 30255 points

That's the only solution available where we have a golden value in ROM. However, you can implement your own CRC of ROM using possibly the VCU CRC capabilities and then store the golden value in your flash to compare against. This will be faster.

Best regards
Chris

0 Alberto Peyro over 6 years ago in reply to Christopher Chiarella

Intellectual 340 points

That's correct but the question would be if you change that firmware in a silicon version, I mean, for silicon revB, we can have different batches with different CRC (e.g. you found an issue in revB, so you keep rev B version name but update firmware), is that possible?