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.

TMS320F28035: Avoiding accidental CSM lock

Part Number: TMS320F28035


Hello,

I have a question regarding CSM locking feature. There are plenty of threads mentioning accidental locks of this device. We are facing similar issues - random fails and device locking using both Jtag or SPI bootloader. I am interested if any of the root causes can be dodged by workarounds. 

There is not much to discuss about power outage but is there an option to actually avoid erasing/programming of Flash sector A at all? Do other reserved parts need some attention/reprogramming or could we just leave it out completely to avoid locking due to interruption of flashing process?

Best regards,

Milan

  • Milan,

                  The most common cause for accidental locking of a device is any kind of interruption to the Erase/Programming process. While the interruption could be in the form of a complete loss of power, it could also be by way of a brownout or even the power source not being able to provide the needed current to the device (current starvation). 

    is there an option to actually avoid erasing/programming of Flash sector A at all?

    Yes, you could choose not to disturb sector A. 

    Do other reserved parts need some attention/reprogramming

    Please clarify. Which other "reserved parts" are you referring to? 

    could we just leave it out completely to avoid locking due to interruption of flashing process?

    If you are referring to sector A, the answer is "yes". 

    What method are you using to program the flash?

  • Milan,

    I would like to add one more point, Sector H is a balanced sector of Sector A. So, on top of Sector A, it is advisable not to disturb Sector H as well.

    Incomplete flash erase / program operation in Sector H can potentially lock the device as reads of Sector A depends upon Sector H as well.

    Regards,

    Manoj

  • I am currently using blackhawk usb200 jtag emulator (bh-usb-200). My other colleagues tested with SPI bootloader and had the same issues which leads me to believe that we actually have some underlying power problem. 

    I was refering to adresses mentioned in technical reference manual:

    1.1.3.3 Reserved Locations Within Flash and OTP
    When allocating code and data to flash and OTP memory, keep the following in mind:
    1. Address locations 0x3F 7FF6 and 0x3F 7FF7 are reserved for an entry into flash branch instruction.
    When the boot to flash boot option is used, the boot ROM will jump to address 0x3F 7FF6. If you
    program a branch instruction here that will then re-direct code execution to the entry point of the
    application.
    2. Addresses from 0x3F 7FF0 to 0x3F 7FF5 are reserved for data variables and should not contain
    program code.

    Do I understand it correctly that I need to program the branch instruction in 0x3F7FF6 and that this is still part of sector A? As in standalone mode it will use the default boot to flash mode?

  • Do other reserved parts need some attention/reprogramming or could we just leave it out completely to avoid locking due to interruption of flashing process?

    You could choose not to use addresses from 0x3F 7FF0 to 0x3F 7FF5. However, not using address locations 0x3F 7FF6 and 0x3F 7FF7 is not an option since they only can contain the branch instruction for the entry point to flash. 

    Do I understand it correctly that I need to program the branch instruction in 0x3F7FF6 and that this is still part of sector A?

    Yes. However, once programmed, you can choose not to disturb this sector, since the code start address in flash is unlikely to change. 

    As in standalone mode it will use the default boot to flash mode?

    Boot mode selection depends on the state of the 3 pins shown in Table 6-1 of the datasheet. 

    I am currently using blackhawk usb200 jtag emulator (bh-usb-200). My other colleagues tested with SPI bootloader and had the same issues which leads me to believe that we actually have some underlying power problem.

    What board are you using? Wanted to highlight this note of caution from the datasheet: "The power supply used should ensure VMIN on the supply rails at all times, as specified in the Recommended Operating Conditions of the data sheet. Any brown-out or interruption to power during erasing/programming could potentially corrupt the password locations and lock the device permanently. Powering a target board (during flash programming) through the USB port is not recommended, as the port may be unable to respond to the power demands placed during the programming process".

  • We are using custom board. I briefly checked the power supply during flash and it seemed ok but I will test a bit more as it seems to be the most probable cause of our issues. 

    Thank you for your help. 

  • Milan,

    How many devices got locked inadvertently? Out of how many? Also, How did you check your power-supply during programming?

  • I will mark this as resolved as the question of avoiding accidental lock by not using sector A was answered.

    I have locked 2 MCU on 2 slightly different boards. On the other hand I programmed those same MCUs several times before that without any issues. I later monitored voltage during flashing with oscilloscope and it was stable at 3.3V. I had trigger at 3.25 and it never triggered. 

    My colleagues on other site were unable to program 2 of 4 boards. On the other hand I was able to program those exact boards without issues on first try so they were not locked. I will continue to investigate. Thank you for your help.