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.

MSP430: Unknown device - problem

Other Parts Discussed in Thread: MSP430FG4618, MSP430F2274

Dear all,

I have a problem on the programming of my Experimenters Board (MSP430FG4618). I know the reason for the problem, but I do not know how to solve it. Let me explain the fault scenario - I work with the mspgcc and the msp-gdbproxy to debug the device.

1) I start the proxy on the MSP430FG4618 (Experimenters Board) in cooperation with a MSP-FET430UIF

2) Accidently I start the programm compiled for the MSP430F2274 (eZ430-board).

3) I stop both, immidiately after programming.

 

After this steps, the MSP430FG4618 is unknown which means:

a) The trial to start the proxy again ends in "msp 430: Unknown device (5)

b) With IAR code composer there is also an error message "... unknown device"

 

My questions:

1) Can I destroy the microcontroller by debugging a wrong program

2) Is there any possibility to erase the device without the JTAG interface (without the proxy)

3) At the last time this error occured, I exchanged the microcontroller on the board, but is this the only way to solve this problem?

 

Thanks a lot for any instruction to solve this problem.

germue

  • That's strange.

    Writing a wrong code to a dvice shouldn't do any permanent damage at all. Maybe except clearing the calibration data in the INFO segment (if there is any).

    You can only flash code to the flash area(s) and if you write a wrong program, well, the flash doesn't care. And if you try to write code to an area where no flash is, well, this won't cause any problems too.

    On some devices, you can rewrite the bootloader code. But this requires a special sequence. Erasing this code will prevent the device from starting.

    One thing that could have happened is blowing the JTAG fuse. But this shouldn't happen except if explictely requested and not by just writing the wrong code. And cannot be dome from within the MSP.

    It's more likely that your program code did something that was causing havoc on the wrong processor. It's still very unlikely, but the only explanation I have. Maybe it's disabling the JTAG port pins internally. Also, on some devices there is an software fuse for the JTAG. A certain memory location in the bootloader area can disable the JTAG except for mailboxing. But writing to this area requires special preparations and cannot be done accidentally (at least it's extremely unlikely).

    So to answer your questions:

    1) It seems so by your experience, but I don't know why and how this happened.
    2) you can use the bootloader (if still active), flashing new code using a serial protocol. But as I already wrote, flashing wrong code to a device shouldn't destroy it, so mass-erasing will not fix the problem, as it's not the flash content that's breaking the device.
    3) if the processor cannot be recognized anymore, replacement is the only way. But I sometimes had similar problems. Not with wrong code but with suddenly reporting 'unknown device' or 'cannot reset device' or similar problems using msp430-jtag. Usually, these disappeared after disconnecting the device from power for some time.

     

  • Bump.  Someone from Ti please answer this.


    This sort of thing happens somewhat frequently.  Recently we've been having a set of boards that loose communication in IAR.   After that we get the

    "MSP430:Unknown device "

     These are good boards.  Have good LDO regulation and communicate for a while.  Then they just wig out

    So unfortunately it is not  an unlikely scenario at all.

    We would also love any help as we are experiencing this same  problem   

     

    Thanks,
    JC

  • There have been similar cases in the past.

    Reason was the supply voltage supervisor. If the program has been programmed with a firmware that accidentally (because compiled for a different MSP with different register mapping) reconfigures the SVS at startup, this may immediately put the MSP into an eternal reset loop. The SVS is NOT reset by the RESET line, only by a power-down. Since the JTAG interface first powers the device and then tries to reset it for entering JTAG, the MSP is already in the SVS reset before the JTAG tries to connect.

    Same is true for the BSL. You'll need to write a PC BSL software (JTAG software) which will permanently hold down the reset line from before the device is powered up until the BSL/JTAG sequence begins, so the MSP will never start to execute the wrong code. Unfortunately, all known softwares assume the device already powered up and of course fail if you start them before the device got its VCC.
    A possible workaround would be to build an external reset logic which will hold down reset after powerup until it was pulled down and up again from the JTAG interface. This would keep the processor in reset state until the JTAG sequence starts, preventing the execution of the faulty code.

    Another possible solution would be to 1) apply 3.8V to VCC (which should be enough for any VCC SVS level) or apply VCC (or even 3.8V) to the external SVS sense pin, in case the SVS has been programmed to sense the external voltage.

    Once the Flash has been erased, things should revert back to normal.

    Mind, this is only a possible solution, in case that the SVS is indeed the source of the problem.

  • Thank you very much for your reply.

    That's a very interesting idea.  Unfortunately, I don't know much about programming the actual JTAG software from scratch so that may beyond what I can try.

    It is interesting though.  If I leave the device un-powered, then program from the MSP-FET430UIF it will program.  I can't run it though, because my system is powered off but this sort of suggests that the thing is in a reset/SVS problem

    Thanks,
    JC

**Attention** This is a public forum