• Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 1299 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.

Code Security Module

Dean Hedin
Prodigy 110 points

In the case of unintentional CSM password lock the device becomes unusable.

Why is it that the erasure of of the device (along with the erroneous passwords) not permitted in this situation?

The purpose of the CSM (as I see it) it to secure code from reverse engineeering.  Not to destroy devices if an erasure cycle is not completed properly (for whatever reason).

TI, please give us the rational by this choice.  Others users thoughts and opinions welcomed. 

 

  • Expert 1240 points

    Yes, I agree with your statement.   For another chip I've used, if the chip was secured, you could always do a bulk erase, clearing the program, and getting back to a "blank" device. 

    Can TI answer this:  Can a bulk erase via JTAG be done, or can a serial flash via BOOT ROM be done to clear the flash to a "blank" state?

     

  • in reply to tom prohaszka
    Prodigy 110 points

    It's nice to know I'm not alone... Thanks for responding Tom.

    Here is my dilema.  We just recieved a pre-production run of 30 boards with 28F12 devices.  One of these boards got corrupted security passwords while loading code using the bootloader method through the serial connection.

    As we enter into production we are to  provide the board vendor with a suitable means of programming the boards.  I intend to provide them with Spectrum Digital's SDFLASH utility to program the boards.

    I have observed rare instances of corrupted security passwords occuring with the JTAG through the IDE and with the serial bootloader method.  My hardware guy goes ballistic when he had to pull/replace the CPU.   I am fortunate that he has also corrupted the passwords while programming.

    My fear is what will happen when the board vendor starts seeing a 1 in 30 failure rate of corrupted passord cpu's. 

    I've written my own serial FLASH utility, that I feel is easier to use than SDFLASH, but I won't risk taking the blame if things go wrong, so I'm not giving the board house my utility.

     

  • in reply to Dean Hedin
    Expert 1240 points

    Yes, I am new to the CCS and the F2803x, and the SDFlash (more experience from other micro vendors like freescale)

    Is there any way to use a custom bootloader, taking the SCI as a reference?  Then, you can always validate the CSM key with a checksum located in flash, and write it prior to exiting.  We are planning on the custom bootloader approach as our tranport is LIN, and what I see with the CSM is a little concerning.  The other thing is have you looked at your SCI signals to see if there are timing issues?  Maybe frame errors are occuring.  Still digging into the BOOT ROM, so I don't know all the details yet on the SCI transport yet.

     I am not sure how to get SDFlash running over SCI yet.  Do you know of a good "how to" for using SDFlash?  I'd like to see it works. Thanks.

     

  • in reply to tom prohaszka
    Prodigy 110 points

    I have written our application so that we can do "in the field programming" via the SPI interface.  But it is not a bootloader. It only works once we have initally loaded our code into the chip.  I just make sure the routines that do the update are located in ram.  This code has never corrupted the passwords BTW.  I wrote it to make sure that I never touch that password sector.