• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 1016 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.

XDS510 emulator unexpectedly resets

David Carney
Prodigy 120 points
Other Parts Discussed in Thread: LM3S3748

We are debugging a system that contains the following:

LM3S3748 Stellaris processor with an XDS560 emulator
5502 DSP processor with an XDS510 emualtor
Both processors use Code Composer 4.2 development environments

There is a SPI bus between the two processors (Stellaris is master, DSP is slave).

We have separate laptops hooked up to the emulators for each processor.  Whenever the LM3S3748 processor is running and producing consistent activity on the SPI interface, and we attempt to run the DSP through the XDS510, it appears to immediately reset and starts running the code stored in the external flash attached to the DSP.  We can still break execution with the emulator, but the code that is running does not match the code in the Code Composer environment (because the processor is running code that was stored in the flash).

We have also noticed resets like this occurring at random times during SPI bus activity on the DSP while executing with the emulator.  We can tell it is resetting by activity on another UART terminal debug port that we have built in to our software, and you can't tell in Code Composer Studio that the reset occurred.

Any ideas on what we should be looking at to figure this out?

  • 0
    TI__Guru**** 465671 points

    Hi David,

    What type of XDS510 and XDS560 emulator are you using? (Vendor, model type, etc).

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 120 points

    The XDS510 is model number 5061160-0001 from Spectrum Digital.

    The XDS560 is model number 512090-0001 from Spectrum Digital.

    Both are USB versions.

  • 0 in reply to Ki
    Prodigy 120 points

    Those look like the models that we have, but the part number stickers on the back of the emulators don't match the part numbers on on spectrum's web site.  We definitely bought them from Spectrum Digital.  The sticker on the back of the XDS560v2 also says Rev C, and the sticker on the back of the XDS510 says Rev A.

  • 0
    TI__Guru**** 171104 points

    David,

    The issue is indeed strange, being much more complex due to its random nature. Even still I have some ideas that may help you go further in the debugging process:

    Are the emulators connected to the board's JTAG connectors before the system is powered up? If not, keep in mind the JTAG interface is not hot-pluggable and therefore any spurious signal may be triggering TRST.

    Does this issue occur if only one JTAG emulator is connected to the system? Since each emulator+laptop combination is completely independent - i.e., different power supplies, grounded/not grounded, etc, I suspect that noise may be introduced through the ground pins of both emulators, which could cause a bounce on the reset pin of the DSP. I would also inspect the signal integrity with an oscilloscope as well. This page may help you with references and additional information, while the datasheet will help you with timings and voltages.

    Did you try to use the XDS560v2 on the C5502 device and see if the random resets still occur? This will give a differential that may or may not individualize the issue to a particular emulator.

    Is there any reset/watchdog mechanism controlled by the data coming from the SPI? I imagine that, if SPI communications fail somehow and the Watchdog is not refreshed this may cause the device to reset. I suppose you are using one McBSP as SPI, therefore I would also inspect the device errata as it contains a few entries about McBSP.

    I will try to think about other details that may be causing this and will get back if I come up with anything useful, ok?

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 120 points

    The problem turned out to be a bug in our design.  There was a buffer overflow in the DSP that was occuring during heavy SPI traffic.  That overflow was leading to a crash in the software which then reset itself without the emulator knowing and started running the code in flash.

    Thanks for the good suggestions on things to look at.  Some of them we did try which actually helped lead to finding the bug.

  • 0 in reply to David Carney
    TI__Guru**** 171104 points

    David,

    Thank you for reporting your findings. They will definitely be useful for other developers in the future.

    Cheers,

    Rafael