• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 278 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.

Error message while programming with the USB FET

Nicholas Rowe
Prodigy 20 points
Other Parts Discussed in Thread: MSP430F5438, MSP430F233

Hello,

I have been using Code Composer Studio v5 to program different MSP430s using the USB FET. I was doing fine programming when I started getting an error message "MSP430: Error connecting to the target: Unknown device" While programming an MSP430F233. I do not get the same error message while programming our MSP430F5438.

For a while I thought the problem might be related to the Reset/SBW port, however I have gone over this pretty thoroughly and looked at documentation and forum posts. I followed:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/147826.aspx?PageIndex=2

to make sure that I was doing everything correctly related to that issue.

I was mostly wondering what causes this error message, so that I can try to track down the problem better. It seems odd that I used to be able to program my MSP just fine, but now I can't. I have tried multiple f233s, and they all have the same result now.

Thanks,

Nicholas Rowe

  • 0
    Guru 227245 points

    When an MSP that worked suddently stops responsifg to the FET, this is usually due to a bad firmware. If the MSP starts a program and then resets before the FET can attach through JTAG, it becomes inresponsible.Especially if the controlling of the MSP is done through USB, which is a high-latency connection. And SBW, if you use it, is quite slow too, compared to 4-wire JTAG.
    The best way to revive an MSP that has fallen to a self-resettign firmware is to perform a mass erase through the JTAG-independent BSL. It rquires attaching serially to the TA0.0 and TA0.1 pins of the MSB and toggling a certain sequence on RST and TEST. Once the BSL has erased the firmware, the MSP becomes accessible again to JTAG.
    Of course don't upload the same firmware again then. :)

    However, it might also be that you up/downgraded the firmware in the FET by installing a different IDE. In this case, the firmware change has removed knowledge of this chip form the FET. It's not very likely that the 5438 is supported by this hypothetical firmware, and the 233 is not, but it is a possibility that would give the same error message.

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

    I'm not sure what the error was, but I came in today and my MSPs are accepting new code like they were before. I don't think I did anything differently, is there a certain order you are supposed to power up the MSP and plug in the FET? I have looked online for some kind of "how to use the FET to program MSPs" guide, I didn't find anything on the subject in the hardware tool user's guide.

    Following the idea that the MSP could be self resetting, is it better to end test code in wait loops, or to let it fall out of the main function?

    Thanks for your time

  • 0 in reply to Nicholas Rowe
    Guru 227245 points

    Nicholas Rowe said:
    I'm not sure what the error was, but I came in today and my MSPs are accepting new code like they were before.

    Sometimes, it is a timing issue. In this case, maybe rebooting the PC caused a reordering in the PCs USB stack regardign other USB devices. And USB latency has dropped by a few µs so the FET gets the commands a bit faster and suddenly things work again.
    At least a possible explanation, even if not a very likely one :)

    Nicholas Rowe said:
    Following the idea that the MSP could be self resetting, is it better to end test code in wait loops, or to let it fall out of the main function?

    usually, the startup code that initializes variables and then calls main, adds an LPM0 or even LPM4 instruction after main returns. THis is, however, unspecified and depends on the compiler, or rather the startup code.
    It's clearer to wait an explicit endless loop or LPM instruction at the end of main.

    Philosophical question: what does 'end of the program' mean on a microcontroller without an OS? Preliminary answer: different things to different persons.

**Attention** This is a public forum