• State TI Thinks Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 18057 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.

MSP430F5342: Cannot bet BSL working again after erasing and re-programming BSL

Joshua van Tol
Intellectual 740 points

Part Number: MSP430F5342
Other Parts Discussed in Thread: MSP430-FLASHER, , MSP-FLASHER, MSP430F5529, MSP-FET

I'm trying to unprotect some previously protected MSP430's and I've run into something strange.

I erased the BSL segments (A,B,C,D at 0x1000 to 0x17ff) and re-programmed. I've used three separate images and none work. Those images are:

BSL.00.06.04.04 From the custom BSL package version 1.00.12.00

BSL.00.07.05.04 From the custom BSL package version 1.00.12.00

Additionally, I've read out the BSL from another (working) board and it is identical byte for byte with 6.04.04. I have verified that the signatures (primary and secondary) are correct, and that the BSL is actually programmed into the device. Just to re-iterate, the "bad" board worked fine until I nuked the BSL and re-programmed it.

When I look at the reset, TCK, RX and TX lines I see correct behavior (Reference SLAU319, section 1.3.2) Comparing a working device vs the non-working device I see everything the same, except that the non-working device never sends anything from it's Tx line.

Trying to debug the boot rom and the BSL is very challenging. The code protection features and some IDE/debugger features seem designed to thwart this at every turn.

I have observed that the boot rom must be calling the BSL_Protect function of the BSL because the SYSBSLPE bit of the SYSBSLC register is set, as are both size bits, which is what the BSL that's loaded into the part is supposed to do.

Is there some configuration item that could have gotten erased when the BSL was nuked that affects BSL operation? I've read everything I can find on the boot, BSL, BSL-Scripter, etc and cannot find anything that's wrong.

  • 0
    TI__Guru**** 223827 points
    What tool and interface are you using to erase and program the BSL area? Is it possible that you are erasing any other memory segments as well? Can you confirm that the BSL flash memory is being re-programmed correctly by reading out the area? And you find that the BSL flash memory (and all of main memory for that matter) between working and faulty units are identical? What is the value of the SYSBSLC register?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 740 points
    Ryan,

    I am using the MSP -FET interface with MSP430-Flasher version 1.3.12
    The command line I'm using is:
    MSP430Flasher.exe -b -w BSL.00.07.05.04.txt -v

    I've then subsequently loaded my application using CCS, and by flipping the SYSBSLPE bit off, observed that the memory from 0x1000 to 0x17ff is correct. In particular, I've verified the signature bytes.

    It's possible that the initial incident, which involved erasing and re-writing the last 512 byte section of the BSL memory programatically could have inadvertently written to some other chunk of memory. I'm at a loss though to think what that other chunk of memory could have been.
    The SYSBSLC register has the value : 0x8003, indicating that the BSL memory protection is enabled for all 4 BSL memory segments.
  • 0 in reply to Joshua van Tol
    TI__Guru**** 223827 points
    Joshua,

    This has only happened to one device so far? Which revision is it?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 740 points

    Only one. I bricked another as well, but in that case, the first section of the BSL is erased (rendering it dead) but the signature and JTAG lock stuff is untouched. It's truly bricked, and I know how that one happened.

    On this particular device, I cannot read the revision level. However, I can read out the device info. That lead me to discover a discrepancy between the device data sheet and the family reference manual (msp430f5342.pdf vs. SLAU208p.pdf). In SLAU208 it says that Firmware revision is first, and hardware revision is next. the 5342 pdf says it's the other way around. Since the 5342 pdf calls out explicit addresses, I'm going with that in my description from this point forward.

    At location 0x1A06 - which should be the hardware revision, we have the value 0x18, at 0x1A07 (firmware rev) we have 0x12.

    Does that help? the 24th letter of the alphabet would be X, so that doesn't make sense to me, but perhaps the number in the device descriptor table doesn't map one to one to rev level.

    Regards,
    Josh

  • 0 in reply to Joshua van Tol
    TI__Guru**** 223827 points
    That is an interesting distinction between the Datasheet and User's Guide, I will be sure to alert the Documentation team of this error. Meanwhile 0x1A06 is the correct address for the hardware revision and a value of 0x18 indicates Rev I (from the Erratasheet). The one known BSL errata was fixed from Rev I to K but this errata does not pertain to your problem, and at any rate the BSL upgrade should have fixed the issue.

    How are you able to program the BSL with a locked JTAG? It would only seem possible to use the resident BSL to unlock the JTAG, followed by JTAG communication to program the BSL. Failure to do this sequentially could lock you out of both programming methods.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 740 points
    This particular part isn't locked, because the last 4 bytes of the BSL flash was erased, along with the rest of the last segment of the BSL.

    Josh
  • 0 in reply to Joshua van Tol
    Intellectual 740 points
    Ryan,

    I've managed to brick another unit. In this case, i had a working unit, which was NOT locked, I erased and re-programmed the bsl with the newer of the two I mentioned above, and now the BSL won't work. I can still jtag it, and it'll still run code that I jtag in, but I cannot get the BSL to activate. Is there something special or different about the BSL that ships with the 5342 vs the one that's distributed?

    Regards,
    Josh
  • 0 in reply to Joshua van Tol
    TI__Guru**** 223827 points
    Josh,

    I'm contacting the Custom BSL experts to comment on this matter.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 740 points
    Ryan,

    Thank you. Let me know if there's further information I should gather or experiments to run.

    Regards,
    Josh
  • 0 in reply to Joshua van Tol
    TI__Guru**** 223827 points
    Josh,

    We are still trying to find leads on your issue but are coming up short, in IAR it would be possible to set the PC to 0x1000 and use the provided debug symbols to further investigate on your side.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Intellectual 740 points

    Ryan,

    I don't have a license for IAR unfortunately. It is possible to set the PC in CCS, but there doesn't appear to be a way to load the symbols. Regardless of that, when I tried to simply single step (at the assembly level) through the BSL, the first time the BSL jumped to a rom routine the CCS debugger lost the plot and had to be re-started. I tried this several times, so it appears that CCS simply cannot deal with that situation.

    Do you have any suggestions that I can move forward with?

    On your side, I think you might be able to reproduce this issue by simply using MSP-flasher to erase and re-program the BSL on a 5342. Then you could presumably use your IAR tools to figure out what had happened.

    Regards,

    Josh

  • 0 in reply to Joshua van Tol
    Intellectual 740 points

    Ryan,

    Anything to report on this? Could you please try erasing and re-programming the BSL on a 5342? That's all I did in the second case, and it made the BSL not work. I think there's a good chance it'll do the same for you.

    Regards,

    Josh

  • 0 in reply to Joshua van Tol
    TI__Guru 56685 points

    Hello Josh,

    I think there is possibly a mismatch between what you are downloading and the BSL signatures. This could cause the newly downloaded BSL to not respond properly. I just downloaded the same BSL as you onto an MSP430F5529 board and was able to access the BSL .The MSP430F5529 is a parent device of the MSP430F5342. To try to clear up this issue, I would recommend the following on a device you have JTAG access to.

    1. Download the Elprotronic Lite FET-PRO 430. Its a free tool from our partner Elprotronic that can help make this process a little easier.
    2. Click Setup > Memory Options, and select the radio button for Used by Code File (including selected BSL). Also ensure all BSL Flash Segments check boxes are ticker directly to the right of this.
    3. Click Setup > BSL Password and Access. disable check box for this as we want to leave the BSL open for now. You can change this later within your BSL image to have a password.
    4. Click setup Connection / Device Reset. Ensure setting here match your JTAG connection type (4 vs 2 wire JTAG) and the correct COM port is selected. Automatic is fine.
    5. Make sure MSP-FET is connected to device then click the ERASE FLASH button on the right side. A Dialog box will pop up confirming if you want to erase all flash, just user defined space, or cancel. Select Yes, Delate all flash contents. (This will include BSL area).
    6. Within the tool, point it to the newest BSL Image for your device. (Open Code File Button, top left)
    7. Click AUTO PROG. on right side to program in the BSL.

    The above procedure should give you a blank device (main flash) with the newest BSL (or the BSL version you programmed in) just as if it came off the factory line from TI. You can confirm functionality of the BSL with the BSL Scripter. Hopefully this helps you out.

  • 0 in reply to Jace H
    Intellectual 740 points

    Jace,

    I followed your instructions exactly, and the result is that nothing has changed. The device still fails the same way. The BSL in the device never sends anything over the UART Tx line.

    As an aside, the EpProtronic tool has an out of date DLL included, and re-flashes the MSP-Fet to an old version of firmware, which then has to be re-flashed again when going back to the TI tools.

    I think I could probably send you a bricked example, complete with the required BSL wiring adaptor if that would help.

    Also, I believe that I've done the equivalent of your suggested procedure using MSPFlasher, with the same results. Do you have any reason to believe that MSPFlasher is doing something wrong?

    Regards,

    Josh

  • 0 in reply to Joshua van Tol
    TI__Guru 56685 points

    Hello Josh,

    As far as MSP430 DLL and Elprotronic tool is concerned, it only recognizes the last DLL it was updated as newest. If you are using the newest version of CCS and have downloaded that DLL onto the MSP-FET, ignore update the Elprotronic tool gives you.

    I am unsure about MSPFLasher as I do not use it often. I do know the procedure in my previous post works as I had just performed it.

    How are you testing the BSL after it is programmed? Can you use BSLScipter to program a Blink LED application onto the device? I can provide this script if necessary for you.

    Can you provide pictures of how you are hooking up the MSP-FET to the MSP430 during programming via JTAG? Also when testing via BSL? If this is a custom board, can you share the MSP430 portion of your schematic? (We can do this via PM if need be.)

  • 0 in reply to Jace H
    Intellectual 740 points

    JH,

    I can provide schematics and pictures, but I will need a private way to contact you.

    Also, it may have gotten lost in all the back in forth but the devices that don't work did work for BSL programming before the BSL was erased and re-programmed.

    Regards,

    Josh

  • 0 in reply to Joshua van Tol
    TI__Guru 56685 points
    Josh,

    Understood about your comment. This is hwy I think the BSL signatures could be misaligned and thus causing your issue. Full erase of everything can fix this. Click on my name and send me a friend request. After I accept, you can PM me.
  • 0 in reply to Jace H
    Intellectual 740 points
    Hmm,

    I tried something different, and now have success. Previously I used the newest BSL version that was available for this part (0.07.05.04) and couldn't get it to work. I just on a whim tried again with version 6.04.04 (which is the original shipped version) and that worked.

    So, I guess my problem is solved, but why didn't the version 7 BSL work? I thought that was the version we were supposed to be using? Also, why can't the same result be achieved with MSP-Flasher (I did try both versions several times with that tool)? It seems like if you're going to offer a tool, you should use it internally and make sure it works correctly for common usage scenarios like this.

    Regards,
    Josh
  • 0 in reply to Jace H
    TI__Guru 56685 points
    Josh,

    One discrepancy with the schematic I see is the UART TX line on your adapter board is pin 11, but your on-board header is pin 10. Is this taken care of within the cable? Otherwise UART TX is not connected to the device.

    I see you posted again as I was writing this reply. Good to know you got it to work now. I imagine if you were to keep the main flash blank and reprogram the BSL with the newest BSL version after you got it working, it will work as well. Again, I think the BSL signatures got mixed up somehow which was causing the fail. I've seen this happen before, but a full erase takes care of the issue.
  • 0 in reply to Joshua van Tol
    Intellectual 740 points
    JH,

    I have another development to report. When I tried the same procedure on 2 other bricked boards, they didn't respond, and remain bricked. I've tried both BSL versions on these boards and nothing works.

    Josh

**Attention** This is a public forum