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.

Continue to Run Problem

Other Parts Discussed in Thread: MSP-TS430PW28

I need some direction on how to fix a problem regarding 2112 development. I am using the MSP-FET430UIF/MSP-TS430PW28 programming/debugging hardware with IAR Workbench IDE.

This is my problem:

Using the tools above I can load an assembly language program to the MSP4302112 part and the application will run and I can debug it.

When I leave the debugging session I select the 'Leave Target Running' option and the 2112 continues to run. (I have the board attached to some I/O and the I/O continues to function indicating the processor is still running).

I consider all of this to be normal and what I would expect.

I have a similar setup with a 2112 on a pcb. I use the voltage from the JTAG module to power the part of the pcb where the 2112 is attached. (No external power applied during programming/debug). As long as I am in the debugger the application runs, I can step through and debug the application, and I can turn individual inputs on and off by toggling their bits in their respective output registers. In fact everything seems to run just fine.

Then I exit the debug mode with the 'Leave Target Running' option selected, but my 2112 doesn't continue to run. It stops and does nothing. When I reenter debug mode again the application will run and I can do normal debugging, such as setting break points, setting/clearing bits, etc.

Will someone please point me in the right direction where I can find information to help me with this problem. It will be greatly appreciated. I am on a deadline, and of course, did not expect this type of problem.

 

Thanks,

 

  • When a device is under debugger ocntrol, some low-power features are disabled.
    When you release the debugger ocntrol, th LPM features will work again, and your program won't work as expected. So there likely is a larger problem with your handling of the low-power modes.

  • Hi Michael, more information are needed to pinpoint problem:

    - the processors have the same silicon code?

    - Have you checked for silicon errata?   http://www.ti.com/lit/er/slaz041d/slaz041d.pdf

     - pcb version is same circuit of prototype?

     - Programmer the same? UIF or other?

     Regards

     Roberto

  • Thank you everyone for your support. Late night debugging found a resistive path between the RST pin and an adjacent pin. The path was strong enough to pull the RST pin down with the I/O pin. Without going into too many details, after I got rid of the path and RST stayed high as intended everything began working as expected.  I am so happy about this.  Thanks again for your comments.

  • Ah, so teh additional (active) pullup of RST during debugger control kept the RST pin high. And as soon as the debugger released control (turning its RST control pin to high-impedance) the MSP was reset and remained in reset state.

    Nasty thing.

    We too got occasional shortcut paths on out industrially made PCBs. Some of them so strong we needed several amperes to 'fry' them away - once we detected them.

  • Jens-Michael Gross said:
    We too got occasional shortcut paths on out industrially made PCBs. Some of them so strong we needed several amperes to 'fry' them away

    With active components in place??

     Regards

    Roberto

  • Roberto Romano said:
    With active components in place??

    Yep. The applied voltage was below the expected input voltages and the connected output high signal. It was just that the output was unable to drive so much current hat it had fried the shortcut by itself.

    Well, removing the active components was not an option anyway (we then had to replace them in any case), and the shortcut was so small that we were unable to locate it with eyesight only (for mechanical removal). It's surprising, how much an 'invisible' trace can stand.

  • Jens-Michael Gross said:

    With active components in place??

    Yep. The applied voltage was below the expected input voltages and the connected output high signal. It was just that the output was unable to drive so much current hat it had fried the shortcut by itself.

    Well, removing the active components was not an option anyway (we then had to replace them in any case), and the shortcut was so small that we were unable to locate it with eyesight only (for mechanical removal). It's surprising, how much an 'invisible' trace can stand.

    [/quote]

    Hi Jeans, I hope this way active components suffer when short burn out, in case of processor suffer a lot from this treatment, you burn trace as resistive but injecting current in traces charge the line inductance to that current and that current continue to draw till magnetic field energy dissipate to shortest way and if cmos is in place it fire parasitic thyristor.

     Ok no other way to find than use a microOhmmeter? I got some defective multilayered board so i drilled them to isolate bad pattern and reroute with wiring but again I searched for short by resistive path.

     Regards

     Roberto

     

  • Roberto Romano said:
    you burn trace as resistive but injecting current in traces charge the line inductance to that current and that current continue to draw till magnetic field energy dissipate to shortest way and if cmos is in place it fire parasitic thyristor.


    Well, I didn't inject a current, I applied a voltage below the maximum allowed for the components. However, the power source was capable of driving up to 10A, and I was slowly rising voltage. When the shortcut was burning away, the same voltage source (or rather its output capacitors) was swallowing any possible voltage peak on the wire. Not that I had thought of that being an issue at all :)

    Roberto Romano said:
    I got some defective multilayered board so i drilled them to isolate bad pattern and reroute with wiring but again I searched for short by resistive path

    A really tiresome way to find such a problem.
    However, if ou don't have high production counts so you can do (afford) an electrical test on the bare PCBs before placing the parts, that's all you can do.
    A tpical example for "when things begin to get cheaper, they start getting even cheaper too" (that's why rich people get more money, poor get less and why sometimes buying some pieces more than you need, will actually reduce the bill)

**Attention** This is a public forum