• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 80 subscribers
  • Views 2704 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.

Security fuse blown - MSP430F5438

Harshith Ramesh
Prodigy 245 points

Other Parts Discussed in Thread: MSP430F5438, MSP430G2231, MAX3232

Hi Guys

I am working on Wireless Sensor Networks, our company has designed a wireless communication protocol which I am supposed to test on MSP-EXP430F5438 kit ,while burning the codes I did not take care of SYSBSLPE bit in SYSBSLC register, may be because of that JTAG LOCK area has been accessed and the JTAG and SBW interface is locked. And I get the following message while trying to program the target :

"Error connecting to the target:
Could not access device - security fuse is blown"

I want help in two places:

1) I need to take care that further kits dont get locked in future, so what steps should I take ? Is it enough if I just set SYSBSLPE?

2) How to recover the locked kit? If its via BSL then please some one give me step by step information as to how to program BSL? I have that JTAG_UNLOCK.txt file and script.txt but I dont using what tool I have to flash it?

Please help me guys:-( :-(

 

Best Regards

  • 0
    Guru 227245 points

    Harshith Ramesh said:
    I need to take care that further kits dont get locked in future, so what steps should I take ?

    You must ensure that the fuse area isn't accessed. However, you shouldn't be able to accidentally blow the fuse at all. Except if you checked the 'blow the fuse' checkbox in your programming software.

    On the FR, the JTAG fuse is part of the normal code FRAM. There it may happen accidentally.

    Harshith Ramesh said:
    2) How to recover the locked kit?

    see here. However, the solution is for the FR chip, where the fuse is part of normal code ram. In your case, you'll have to go one step further and upload a firmware that restores the fuse by writing 0x0000 to the fuse bytes of the BSL area. If you fail, you will blow the BSL too and the MSP is loked forever.
    But there are two doubts: if you have an MSP430F5438 of the NON-A series, you shouldn't be able to blow the fuse at all (the BSL area is not writable and so is the fuse).

    A mroe likely reason for your lockup is that you uploaded a software that puts the MSP into a constant reset cycle, In this case, the JTAG interface cannot attach to the MSP (becaus ebefore it can complete the attach sequence, the MSP resets and the JTAG connection is lost again). This results in a wrong 'fuse blown' error.
    To solve this, the solution pointed to above is sufficient, as it will erase the faulty code.

  • 0 in reply to Jens-Michael Gross
    Prodigy 245 points

    Hey Jens

    Thank you for replying:-)

    Jens-Michael Gross said:
    But there are two doubts: if you have an MSP430F5438 of the NON-A series, you shouldn't be able to blow the fuse at all (the BSL area is not writable and so is the fuse).

    I am using MSP-EXP430F5438 kit the MCU is XMS430F5438 , I am programming the MCU using a launch pad MSP-EXP430G2 it has MSP430G2231 mcu, using 2-Wire spy-by-wire method.

    Jens-Michael Gross said:
    To solve this, the solution pointed to above is sufficient, as it will erase the faulty code.

    I went through your replies in the link you have given,

    Jens-Michael Gross said:
    You should be able to program the MSP thorugh the BSL (using an external TTL/RS232 converter attached to the proper pins and using the BSL scripter software on PC).

    you have mentioned to attach to the proper pins, can you please specify which pins? Is it possible to flash the FRAM using USB protocol with same launch pad.??? Is there any specific TTL/RS232 converter or any normal converter will do?

    Jens-Michael Gross said:
    Normally, this shouldn't happen at all. But it is possible (I didn't check, as I don't use IAR or CCS) that the segments are defined improperly, so maybe the linker places code where the JTAG fuse is. (auto-protection :) )

    Which compiler and debugger you use?

    Best Regards

  • 0 in reply to Harshith Ramesh
    Guru 227245 points

    Harshith Ramesh said:
    I am using MSP-EXP430F5438 kit the MCU is XMS430F5438

    THis is the experimental, preliminary version of the 5438. I wouldn't trust that it behaves as a real MSP430F5438 should. And it is not officially covered by any datasheet/errata sheet.

    If you encounter any weirdness with an XMS device, don't wonder, proceed with a 'release' version. :)

    Harshith Ramesh said:
    I went through your replies in the link you have given,

    Hopefully not jus tmy replies. The solution was given by someone else. :)

    Harshith Ramesh said:
    you have mentioned to attach to the proper pins, can you please specify which pins?

    See teh 'Bootstrap load (BSL) section of the datasheet.

    Harshith Ramesh said:
    Is it possible to flash the FRAM using USB protocol with same launch pad.

    No for some reasons: 1) FRAM cannot be flashed. FRAM is random access and can be written like normal ram. So 'flashing' FRAM won't work at all. For this reason. The FET used with an FRAM device requires to support exatly this device, which is not true for the LaunchPad FET.
    Also, the 'USB-protocol' is just a USB->serial converter that accesses teh 1612 processro in the FET part of the LaunchPad. And it has nothing todo with BSL. If the fuse is broken, the fuse is broken, and neither LaunchPad SBW-JTAG nor normal JTAG will work. The BSL is a completely different, independent way that relies on executing some bootstrap code inside the target MSP, while JTAG/SBW takes control over the CPU - if the CPU doesn't reset before control is gained.

    Harshith Ramesh said:
    Is there any specific TTL/RS232 converter or any normal converter will do

    Any will do, e.g. the MAX3232. Or you go for an USB->ser converter with TTL compatible output (such as the FTDI chips). Then you don't need a real COM port on the PC and no level shifting. However, msot prebuilt USB->RS232 converters have RS232 output levels. (and contain some sort of MAX3232 themselves)

    Harshith Ramesh said:
    Which compiler and debugger you use?

    I use MSPGCC, as it was free when development started in my company. And now most of the code is written and optimized for MSPGCC, so I don't think we'll switch.
    Sinc emsot of our code is realtime stuff, I don't use a debugger at all. My debugger are LEDs, portpins, a scope and a frequency counter/timer. And for high-level debugging output a serial port for plain text messages. But I also used PWM duty cycle to output numerical values on projects without serial port.

  • 0 in reply to Jens-Michael Gross
    Prodigy 245 points

    Hi Jens,

    Thank you very much buddy ..... you solved many of my problems:-)

    One last question....:-)

    I have USB to serial converter, please tell me which pins should I connect, am attaching the pics of DB9 connector and JTAG header please tell me which pins should I connect?

  • 0 in reply to Harshith Ramesh
    Guru 227245 points

    Harshith Ramesh said:
    I have USB to serial converter, please tell me which pins should I connect, am attaching the pics of DB9 connector and JTAG header please tell me which pins should I connect?

    Aehm, none of them. The 14-pin JTAG header does not contain any RS232 signal. It is a plain FET-to-MSP programming interface.

    Okay, that's not entirely true. the BSL uses teh RST/NMI pin and the TEST pin (or on some devices without a TEST pin the TCK pin I think) for entering the BSL mode. IIRC, DSR adn RTS signals are used for the two. RxD adn TxD go to TX and RX pins of the BSL (which are NOT necessarily the RX and TX pins of the MSPs hardware UART, since the BSL usually does not use the hardware UART but TA0.0 and TA0.1 pins instead.

    Details are listed in teh device datasheet.

    However, the USB/serial converter usually outputs RS232 level signals, whcih are symmetrical (including negative voltage) and inverted. YOu'll need a levle converter like the MAX3232 to turn them into MSp compatible TTL logic levels. However, most USB/serial converter have a device liekt eh MAX3232 internally too. If you curt it from the SUB controlelr chip, you may be able to use the USB controllers outputsignals directly, wihtout an additoinal chip (but maybe a 1k series resistor to limit any currents due to different suppy voltages).

    P.s.: on some software (not the BSL scripter, but some terminal programs), it can be necessary to loop DSR back into DTR, so the program sees that there is a peer on the other end of the line. else they might ignore incoming data as noise.

  • 0 in reply to Jens-Michael Gross
    Prodigy 245 points

    Hi Jens

    I feel the problem is almost solved...:-) I did my own BSL programmer but there is some hardware , anyways I have ordered a new ready one... meanwhile I found out a reason for MCU to go on continuous reset loop...

    Actually am defining a long array may be around 1K , and I have disabled watch dog timer in main function, what happens here is the array is getting initialised before the main function and here i feel that watch dog timer creating problem, IIs there any method to stop self initialisation?

    Best Regards

  • 0 in reply to Harshith Ramesh
    Guru 227245 points

    This has indeed been a problem on the older MSPs (WDT only 32768 counts, driven by DCO). The MSPGCC startup code did silently disable the WDT before initializing the variables. Which surely isn't exactly what you want when you actually need the WDT.

    CCS does not initialize variables (or arrays) which have no explicit initializer.

    So "char x[y] = {0}" is initialized, "char x[y]" is not and contains random values at program start. IAR initializes both to 0, as does mspgcc.

    On newer MSPs, the WDT has a larger default count range and also derives from internal REFO  instead of DCO by default. Since RAM hasn't increased that much, it isn't a problem anymore.

    But on the 1611 with its 10k ram, it was an issue (I think, the limit was around 4k of initialized variables)

  • 0 in reply to Jens-Michael Gross
    Prodigy 245 points

    Hi Jens

    Jens-Michael Gross said:

    CCS does not initialize variables (or arrays) which have no explicit initializer.

    Actually in hal_lcd.c we initialize a big array with explicit initializer. Is there a way to solve this problem? In Iar Kickstart there is a function __no_init() but in CCS there is a different option but there are lot of limitations also.

    Can you suggest me a way how can I do it in CCS.

    And I am planning to go for MSPGCC after this project can you please give me the links how to install msp430-gcc, debugger and simulator.

    Do you know any simulator where we can simulate our codes efficiently ?

    Best Regards

  • 0 in reply to Harshith Ramesh
    TI__Guru* 83021 points

    Hi Harshith,

    Harshith Ramesh said:
    In Iar Kickstart there is a function __no_init() but in CCS there is a different option but there are lot of limitations also. Can you suggest me a way how can I do it in CCS.

    If you want to still initialize your array but not have your watchdog timeout, the way to do this is to add the _system_pre_init() function and put a line of code in it to stop the watchdog (WDTCTL = WDTPW + WDTHOLD;). Use of this function is documented in the Code Composer Studio User's Guide for MSP430 (SLAU157) on p. 22 section A.2. The first thing in that list talks about how to disable the watchdog before your variables are initialized, therefore keeping you from hitting a timeout with large data arrays - just copy the function listed there into your code.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 245 points

    Thank You Very much Katie and Jens, You have solved lot of my problems, in future no kits will be locked....:-)

    By the way now I am trying to revive the old kits(XMS430F5438 mcu)  which was locked, the BSL programmer is designed according to the design given in the pdf file, but still there is following errors:

    1) MASS ERASE  fail(ee)

    2) RX PASSWORD fail{ee) or fail(4e)

    What might be the problem? It initializes the com port..

    Best Regards

**Attention** This is a public forum