• State Resolved
  • Locked Locked
  • Replies 24 replies
  • Subscribers 84 subscribers
  • Views 4444 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.

Recovering erased BSL

Pak Woon
Prodigy 105 points
Other Parts Discussed in Thread: MSP430F5438A

Hello Forum Members,

We are currently using a MSP4305438a for one of our projects and have managed to lock ourselves out of the device. We are planning to use the BSL interface to upgrade our devices in the field and in the process of trying to get that to work, we've somehow disabled JTAG access. In trying to recover JTAG access, we performed a sector erase (via BSL) on 0x17FC and now both JTAG and BSL access fails.

We have been using mspdebug via JTAG and a MSP-FET430UIF pod (with mspdebug tilib) to do development without any issues. We were also able to access the device via the BSL using mspdebug and a RS232 level convertor (with mspdebug flash-bsl after fixing a bug in the library). We were also able to successfully program our code into the device via the BSL. However, when we tried returning to JTAG mode, we were unable to access the device.

We dumped memory location 0x17FC and saw 0xFF 0xFF 0xFF 0xFF which, according to the datasheet, should mean JTAG is accessable but this was not the case. And given that it did not work, we tried programming 0xFF 0x3F 0xFF 0x3F (since we saw that on a second board via JTAG), but that did not work either. As a final desperate act, we used BSL to sector erase 0x17FC, at which point the application timed out and on a restart, could not access the device via BSL.

Are we able to obtain the BSL hex file from somewhere to reprogram into the device?

Regards,

Pak

 

  • 0
    TI__Guru 56650 points

    Pak,

    the BSL binary is available in the associated files of SLAA450.

  • 0 in reply to Leo Hendrawan
    Prodigy 105 points

    Hi Leo,

    Thanks for the prompt reply. I'm pretty sure I've blown the security fuse and subsequently erased the BSL. Is there anyway to recover this device?

    Regards,

    Pak

  • 0 in reply to Pak Woon
    TI__Guru 56650 points

    Pak,

    if the JTAG KEY (in the BSL flash memory area) is either FFs or 00s, the JTAG should be accessible. If you erase completely the BSL area, the JTAG key should be FFs. I wonder why it is not working then.

    Basically there are only three ways to get access into the device:

    - JTAG (can be disabled if JTAG KEY is not FFs or 00s)

    - BSL (can be disabled by putting false BSL signature or completely erasing the BSL memory)

    - through application if you implement this in the application itself.

  • 0 in reply to Pak Woon
    Mastermind 7925 points

    Pak,

    As Leo said if you know the key you can recover device: 1.4.2 Programming the JTAG Lock Key - Function Reference for 5xx Family http://www.ti.com/lit/ug/slau320i/slau320i.pdf (MSP430™ Programming Via the JTAG Interface User's Guide)

    Regards,
    Maciej

  • 0 in reply to Leo Hendrawan
    Prodigy 105 points

    Hi Leo,

    So the statement in slau320i section 1.4.2.

    "Any value other than 0 or 0xFFFFFFFF programmed to these addresses irreversibly locks the JTAG interface" is incorrect then?
    With regards to the erasing the BSL, it all depends on which way the sector was erased. Does it erase from 0x17FF or from the other end of the sector?
    Regards,
    Pak
  • 0 in reply to Pak Woon
    TI__Guru 56650 points

    Pak,

    i agree it is not 100% correct wording. Basically you can reverse it if you still have access to the JTAG key (e.g. via BSL) - i have tested it myself (should have written an app note for this) and there are many discussion also about this in the forum which you can try to search.

    I am not sure I understand your second question regarding erasing the BSL sectors. Can you please explain it more clearly?

  • 0 in reply to Leo Hendrawan
    Prodigy 105 points

    Hi Leo,

    We used the mspdebug command 'erase segment 0x17FC' which should have erased everything from that sector/segment. Given that BSL code executes out of that sector (and this is a guess) the erase could have erased the BSL code before it got a chance to complete the erasure of the key. Either way, I have no idea what the key was set to, no way to access the device via Jtag or BSL (so I can't load code into it) so it pretty much means this prototype board will be binned.

    Thanks for you help. I will open another post with another issue I noticed during BSL programming.

    Regards,

    Pak

  • 0 in reply to Pak Woon
    TI__Guru 56650 points

    Pak,

    i am not familiar with mspdebug, but just want to ask whether you are aware that the BSL flash memory per default is protected through SYSBSLPE bit of SYSBSLC register (user's guide shows reset value of 0, but if im'm not mistaken whit will be set by boot code during startup)

  • 0
    Guru 58965 points

    Be aware that bad code in the Main Flash could lockup JTAG access even when 0x17FC-0x17FF are all 0xFF or all 0x00. This fact is undocumented but has been observed by many others,  I suspect that you are another victim in the early stage of your adventure. Your actions after that made the situation worse.

    Pak Woon said:

    ...  In trying to recover JTAG access, we performed a sector erase (via BSL) on 0x17FC and now both JTAG and BSL access fails. ...

    Erasing BSL Flash without writing BSL code back will lockup BSL access the next time you try BSL. But this will not lockup JTAG because 0x17FC-0x17FF are all 0xFF after the erasure. Bad code in Main Flash can still lockup JTAG access.

    Pak Woon said:

    ...  we tried programming 0xFF 0x3F 0xFF 0x3F (since we saw that on a second board via JTAG), ...

    Reading 0xFF 0x3F 0xFF 0x3F at 0x17FC-0x17FF is an illusion caused by BSL Flash being protected. Try to Erase BSL Flash and rewrite those bytes is a bad move. That act will disable both BSL and JTAG. After that the chip is essentially useless forever.

    -- OCY

  • 0 in reply to Leo Hendrawan
    Prodigy 105 points

    Hello Leo,

    I have successfully "recovered" my device and can access it via JTAG. It had nothing to do with the BSL, it was a hardware specific issue with my board.

    Thanks again for your assistance.

    Regards,

    Pak

  • 0 in reply to Pak Woon
    Guru 227245 points

    Pak Woon said:
    he erase could have erased the BSL code before it got a chance to complete the erasure of the key.

    Erasure of a flash segment happens simultaneously (and in hardware). Teh software is only triggering the process.
    All 512 bytes of a segment are vanishing at the same time (well, more or less, as all '1' bits don't need to be erased a tall, and there might be some time jitter in when the other bits flip back form 0 to 1).

  • 0
    Prodigy 175 points

    Hello Pak,

    I read that you are able to successfully program a msp430f5438a device via the BSL using mspdebug and a RS232 level convertor (with mspdebug flash-bsl after fixing a bug in the library).

    I understand that you program the msp430f5438a via FT232 chip which is USB-UART bridge. From the FET232, you connect RTS to the TEST pin and DTR to the RST pin.  So, the bootloader entry is accomplished via the RTS and DTR lines. Is this right?

    But the manual of mspdebug says that the flash-bsl driver is not supported via USB connection. How do you use the mspdebug command? and What bug did you fix in flash-bsl?

    Best regards,

    Rafa.

  • 0 in reply to RAFAEL MARIN
    Prodigy 105 points

    Hi Rafa,

    The device I am using from the PC is a FTDI FT4232HL which is a USB to RS232 convertor. The command I used was :

    sudo ./mspdebug -d /dev/ttyUSB1 -–long-password flash-bsl

    I had to modify mspdebug-0.21/driver/flash_bsl.c to flush the UART by adding:

    sport_flush(dev->serial_fd);

    just before flash_bsl_open() and after the delay(500);

    Regards,

    Pak

  • 0 in reply to Pak Woon
    Prodigy 175 points

    Hi Pak,

    I have used the configuration of the USB-RS232 converter, but the mspdebug command fails with the following error:

    $ mspdebug -d /dev/ttyUSB0 --long-password flash-bsl

    flash_bsl: incorrect response header received
    flash_bsl_erase: no response
    flash_bsl_unlock: warning: erase failed
    flash_bsl: incorrect response header received
    flash_bsl_unlock: error receiving password response

    Do you know the reason of this error??

    Best regards,

    Rafa.

  • 0 in reply to RAFAEL MARIN
    Prodigy 105 points

    Hi Rafa,

    Did you add the sport_flush(dev->serial_fd) to flash_bsl_open()?

    The error message "incorrect response header" is from line 187 of ./drivers/flash_bsl.c in the routine flash_bsl_recv(). flash_bsl_recv(), I believe, it is called from flash_bsl_open() which is where you should have inserted the sport_flush().

    The way I found the error was dumping out the bytes received from the UART. You can see what the MSP430 responded with by printing out to console the recv_buf.The data should match the data packet format in Chapter 3 of slau319d.

    Regards,

    Pak

  • 0 in reply to Pak Woon
    Prodigy 105 points

    Sorry, correction. You can read out the bytes from header[3] in flash_bsl_recv() after the sport_read_all() call on line 181. The rest of the data is avaliable from recv_buf after sport_read_all() on line 204.

  • 0 in reply to Pak Woon
    Prodigy 175 points

    Hi Pak,

    I am going to add the  sport_flush(dev->serial_fd) to flash_bsl_open() and print out to console the recv_buf. I will tell you the results later.

    Best regards,

    Rafa.

  • 0 in reply to Pak Woon
    Prodigy 170 points

    Hi Pak and Leo,

    I have somewhat similar issue regarding my dev. board. I was trying to write to JTAG area of BSL code and it worked first time (I was able to enable and disable the JTAG), but when I tried it next time the board stopped responding. JTAG got disabled and I cannot enter into BSL even using pressing switch (S3) on USB.  

    At this point, I am not able to do anything. Cannot load any user program, since I cannot get into BSL mode and JTAG security fuse is blown.

    Can you please share what was wrong in your case and how did you fix it?

    To Leo,

    Do you know any other way I can fix this issue without replacing the chip. Is there a way I can get into BSL mode or enable JTAG?

    Thanks,

    Deepak

  • 0 in reply to Deepak Yadav
    Guru 58965 points
    I read your other post too. It is not clear to me exactly what you did and what happened to your chip.

    The BSL function depends on the integrate of almost every byte of the protected Flash from 0x1000 to 0x17FB. Whereas JTAG Fuse involves 0x17FC to 0x17FF only. Furthermore, the JTAG Fuse enables/disables JTAG after the next BOR, not immediately.

    If indeed you disabled (damaged) both BSL and JTAG Fuse, there is no known way to revive the chip unless you have the foresight of loading the Flash with a code to revive it ahead of time and a way to invoke it afterwards.

    Theoretically, you could also put the chip in high temperature for a long time, or subject it to high dose of ionization radiation and wait for Flash retention limit to expire and change the JTAG Fuse to all 0's.

    But in practice, there is a solemn warning on the gates of hell -- Dante: Give up all hope.
  • 0 in reply to old_cow_yellow
    Prodigy 170 points
    Thank you for your reply. What I am trying to do is I am building a custom BSL firmware update UI that can have bunch of options and one of the options is to enable/disable JTAG for security purpose.

    To test this feature, I was compiling and running the JTAG enable and disable code in CSS and used FET debugger for disable test and then used USB with BSL firmware update UI(I used TI BSL UI) to flash new code with JTAG enable function.

    I used the following code for enabling and disabling. I wasn't writing to the main BSL memory location(0x1000 to 0x17FB). I was writing to the JTAG fuse memory location (0x17FC to 0x17FF).

    char A;
    A=85; //0x55->for disable 0x00--> for enable
    Flash_WDptrA = (char*)0x17FC;
    SYSBSLC = 0; // enable and unlock BSL segment 3
    while(FCTL3&BUSY); // Check BUSY flag
    FCTL1 = FWKEY + WRT; // Set WRT bit for write operation
    FCTL3 = FWKEY; // Clear Lock bit

    for (i=0; i<4; i++){
    while(FCTL3&BUSY); // Check BUSY flag
    *Flash_WDptrA++ = A;
    //printf("%d: 0x%02X\n", i,A);
    }

    while(FCTL3&BUSY); // Check BUSY flag
    FCTL1 = FWKEY; // Clear WRT bit
    FCTL3 = FWKEY + LOCK; // Set LOCK bit

    It worked the first time. Second time it didn't work. I was trying to disable the JTAG again, but I wasn't able to do it.

    The mem readback from 0x17FC-0x17FF remained constant and never changed no matter how many times I write to it (I even power cycle the board). I tired with FET debugger and CSS and even with USB using BSL firmware update UI.

    So I follow some suggestion on the TI's fourm to enable the read/write access to BSL under project properties (as I have posted the screenshot on my other post: e2e.ti.com/.../1899068

    After this seetings I was able to disable the JTAG (I used FET debugger to program it). Now to enable it again I used USB firmware update UI and it stopped responding. This time I wasn't able to get into BSL using the USB and the switch on the board.

    I am getting a new chip and this time I want to make sure that I don't blew up this one too :) So I wanted to know how can I safely enable and disable the JTAG without touching the BSL (which I thought what the above code is already doing, but I guess somehow BSL code got corrupted).

    I wanted to know what might have cause this issue. If it's BSL mem data then how it got erased? I need to know these things so that it wont happen next time.


    Sorry I have written lot of things above. I hope this time I was able to explain it better. Please let me know if you want to know somethingelse.

    One more question: Does TI have some examle source code on JTAG enable/disable feature?

    Thanks,
    Deepak
  • 0 in reply to Deepak Yadav
    Guru 58965 points
    Your code to change the JTAG Fuse bytes has one limitation that you were not aware of and that started your problems.

    That code is capable or changing the JTAG Fuse bytes from 0xFFFFFFFF into anything else (including 0x55555555). It is also capable or changing the JTAG Fuse bytes from 0xx55555555 into 0x00000000. But it cannot change from 0x00000000 into anything else. This is a fundamental property of Flash memory and is fully explained in the User's Guide.

    But the real damage is actually caused by trying other things after you found you cannot change the 0x00000000. I am not familiar with CCS and other fancy tools. Whenever I tried to use them, I end up like Charlie Chaplin in Modern Times.

    I only understand how the hardware works. This is what I would do:

    (A) While both JTAG and BSL are still working, I would write a small program to unlock the BSL protection and dump the contends of location 0x1600 to 0x17FB. I would lock up the protection after that and try to convert the dump into source code of a constant array of 508 bytes (or 254 words, or 127 double-words).

    (B) I would then write the program to be loaded by BSL in order to enable the JTAG. Inside this program, I would include a constant array that was obtained in (A) above. This program essentially unlocks the BSL protection, erase the Section at location 0x1600 to 0x17FF, and copies the constant array to locations 0x1600 to 0x17FB. This leaves the BSL code unchanged (because it was erased and copied back) but the JTAG Fuse erased and not altered by the copying. But it is not that simple, it should take extra steps so that even if the system crashed (e.g., due to power glitch) in the middle of it, it can still recover from with no harm done.

    I would do the above with the most primitive tools that I know how to use rather then use fancy tool which I have no idea what it does. (I prefer to use my bare hand if I could get away with that.)

    You can use whatever you are comfortable to use to achieve the same objective. If it is in simple and straight c, I may be able to read it and help. But if it involves "Drivers", "Wares", and other canned stuff, I am out.
  • 0 in reply to Deepak Yadav
    Guru 227245 points
    As OCY already wrote: FLASH memory can only be written bit-wise from 1 to 0. If you need to go from 0 to 1, then you have to erase a whole segment of memory. So you were able to change the fuse from 0xff to 0x55 and from 0x55 to 0x00. But there is no way to change just the fuse from 0x00 to 0xff (or 0x55) again. When you ordered one of your tools to write 0xff to the fuse location, thsi tool had to erase a whole memory segment (that is 1/4 of all BSL code). And you didn't order it to save this content before and restore it after erasing the segment.

    In other words: you have locked the door and thrown the key away. You chip is bricked.

    For the next attempt, I suggest playing with the INFO memory first instead of the BSL memory. Fill it with magic words (a known value that is not common, like 0xDEADBEEF), then experiment with your code to alter just a certain byte or word back and forth in this info memory without changing any of the other bytes in the same info memory segment.
    Note that there is also a limit for the maximum number of writes between two erase operations. So you can't count a single word down from 0xffff to 0x0000 without an erase in-between (with backing-up the other segment content and restoring it after the erase).
    Once your code does this, and in a bullet-proof way (including a possible power-failure), then you can start your second approach on the 'real thing'.
    In any case, you'll need a new MSP. Luckily, these are quite cheap.
  • 0 in reply to old_cow_yellow
    Prodigy 170 points
    Thanks old_cow_yellow. You solved my problem. Your explnation of right way to read and write flash was awesome. I did exactly what u descibed in steps A and B and got this thing working!!!.... I used CSS and c lanaguga. I wrote a simple function that read the segment store into an array. Erase the segment and the write back the segment with previously sotredd data. THANKS for the explanation.
  • 0 in reply to Jens-Michael Gross
    Prodigy 170 points
    Thanks for your suggestion Jens-Michael Gross. After reading old_cow_yellow post I followed your suggestion and tried to do my experiment with the INFO memory just to be safe and it worked. What you said was right. MY code wasn't backing up the BSL data and re-storing it after the modification. I put thoes in there along with the segmetn erase on each write and got this thing working.

**Attention** This is a public forum