TMS570 Not Starting Without Debugger (sometimes)

Brian,

Please let me know the following :

1. Are you sing the TMDX570LS20SUSB  http://focus.ti.com/graphics/tool/TMDX570LS20SUSB.jpg  ?

2. Is the code generated by HALCoGen or was it modified after generation?

3. Would you be able to share the boot up code or the start up sequence if its not generated by HALCogen ?

Regards,

Pratip

Pratip,

1. I'm not using the TMDX570LS20SUSB. I'm using Trace32, Lauterbach, IAR ARM Compiler, and no TI tools
2. No code is generated by HALCoGen.
3. 1462.Boot_Up_Code.zip

Thanks,

Brian

Brian,

The TMS570LS series always boot in ARM mode after a reset (Cold or warm start)

What I suspect is an initialization problem in your code/environement.

I'm not familiar with Lauterbach tools, but maybe while in debug mode, a variable is initialized by the debugger.
When you then disconnect the debugger and reset your application (Reset does not affect the content of the RAM) your code works fine.

In opposition, when you start out of power on, the RAM contents is trash.

I looked to your boot code, and my question is how the different stacks are initialized?

    cps    #PSR_SVC_MODE
    msr    spsr_cxsf,#0       
    ldr    sp,=sc_svc_stack
    mov    r14,#0xf50

Where sc_svc_stack is defined?

Will it be possible to share your boot code (exe) so I can run the code on my environement?

Regards,

Jean-Marc

We are using SCIOPTA RTOS. Look in sciopta.s79 ( 5001.sciopta.zip ) and you'll see where "sc_svc_stack" is defined.

Thanks,

Brian

Brian,

To better understand your I need a little more detail on the failure you are seeing.
Let me summarize what I understand.

Please answer the following questions:

1] Whenever the debugger is connected to your application, your code is always running fine. Yes/No

2] Whenever the debugger is not connected to your application, your code is always not running. Yes/No

3] When the debugger is connected, and the code is running, if you disconnect the debugger and reset your application (warm reset) the code is still running fine. Yes/No

When the JTAG cable is plugged to your application, your debugger will tie the nTRST high.
The only effect of nTRST is on the debug logic, and should not affect your application.
Anyway, there is a corner case where the nTRST (high or low) has some effect.

On almost all the IO pins, there is a way to select the type of Pull (Up or Down) and a way to disable the pull (no pull at all)
This is done via the Pul_Dis and Pul_Sel bit. Here is the table for these bits:

               Pull Dis            Pull Sel     Pull        Input Buffer
                  0                       0          Down       Enable
                  0                       1          Up           Enable
                  1                       0          none        Disable
                  1                       1          none        Enable

This table is valid when nTRST is low. When nTRST is high, the input buffer are always enable regardless to the configuration of Pull_Dis and Pull_Sel.

So if in your application you have selected no pull, Disable input buffer, during debug, your code will still be able to read the state of an input pin. When the debugger is disconnected (nTRST is low) the same code will not be able to read the state of an input pin.
If this is the case, your code may be in an infinite loop, waiting for some event from outside. (SCI communication, GIO, SPI data,,,,,)

Please let me know if you are in this case scenario.

Best Regards,

Jean-Marc

1. Yes

2. When the debugger is not connected, the code does not run sometimes.

3. Yes

Below is the status of GIOPULDIS, GIOPSL, and GIODIR in our code.

• We are not using GIOPULDIS
• We are not using GIOPSL
• GIODIR is set to 1

So, it appears we are in the following scenario:

X = Don't care

After further analysis of the code, my earlier reply was not complete.   

1.  Yes.  It runs as expected when the debugger is connected and the program running.

2.  With the debugger not connected the code sometimes does not run at all, and sometimes "runs" but not completely correctly.    The part that does not run correctly appears to be related to not receiving interrupts on the GIOA6 pin.   If the debugger is plugged in, but the program is not running, the code usually will not run at all.

3.  Sometimes.   See below.

Our code has a mixture of input and output GIO pins (on port A, B, and the NHET pins).  As far as I can tell, there are no pins with DIR=0, PULDIS=1, and PSL=0.  Also as far as I know there are no infinite loops waiting on a pin state.   Will a single read to GIODIN on a pin with the input buffer disabled hang, or will the read just read an indeterminate value?

Our board has 2 reset buttons.   One of them is labeled "Reset", I don't know what pin it goes to.  The other one is labeled "PORST".

Running with debugger connected, program open  ->  unplug debugger  ->  board appears go into reset at this point.

Running with debugger connected, close program, then unplug debugger -> board continues to run.

With code running after unplugging debugger  ->  press "reset" button  ->  code resumes running correctly.

With code running after unplugging debugger  ->  press "PORST"  ->  sometimes resumes running but not correctly, sometimes won't resume at all.  (Same as #2 above.)

I also have the same problem with power up sequence and I dont have specified componet to do that thing. It makes the system rarely start without debugger.

Is there any way to elimianate that problem ?

We are having "almost" the same problem of Brian regarding the cold power-up of the TMS570LS20216 MCU.

I will try to understand Donnan's suggestion to see whether that solves our problem.

Thanks!

S Donnan said:

We had inconsistent startup behavior on one of our designs that had me stumped for a while. Ended up reading through the Rev A. silicon errata and found that DEVICE#167 described similar symptoms.

Can anyone please let me know what is the DEVICE#167 referring to in the Errata Rev. A? I searched through the Errata but only be able to find this one pertaining to device reset:

Page 75: SYS#103 - Pulse extension needed to ensure device reset.

Thanks.

I have been unable to relocate that particular errata. If I get a chance I will go back through my notes and let you know.

Here are the links for the errata documents:

For TMS570LS20216 http://www.ti.com/lit/er/spnz176d/spnz176d.pdf

For TMS570LS3137 http://www.ti.com/lit/er/spnz181a/spnz181a.pdf

Thank you for the information.

I switched from TMS570LS20216 to TMS570LS3137 a couple months ago. This issue seems to be resolved with TMS570LS3137.