TM4C129ENCPDT: Tiva microcontroller locking

Hi Jim,

Jim Brinkhurst1 said:

We've had at least 8 of the Stellaris chips lock up in the past and now we think we have two of our new boards with the Tiva lock up.  Working on getting a USB wired up to try the unlock sequence on the Tiva.

  I have some questions. 

  - When you said the device is locked, you meant the debugger can no longer connect to the device, correct? 

  - Are the boards (especially the 2 Tiva boards) immediately locked up after the code is loaded or they have been running for sometimes before they become locked. 

  - You mentioned that you are working to unlock the device. Has the unlock been successful?

  - If the unlock is successful, then can you reload the same code again and what will happen? Will it lock up again?

Jim Brinkhurst1 said:

but our testing has shown that we can make a build which flashes correctly, then add a C printf statement and get the chip to lock. 

  - I'm unaware that a C printf can make the device lockup. I wonder if you have enough stack space reserved. The C printf is normally not ideal for real-time logging. The printf can take up quite some memory space. If you don't have enough stack space, then you can get a hard fault from the processor. But normally a device is not locked when a fault is detected, meaning the debugger should still be able to connect to the device.

  - If the C printf can lock up the device then it should be repeatable. Can you repeat the problem on other boards or only one specific board?

  - If the C printf can lock up on any boards you have then please send me the CCS project so I can replicate it on my end with exactly the same code. 

Jim Brinkhurst1 said:

who can explain the Tiva causes and how to avoid it?

  Normally, a device can lock up if the application re-purposes the JTAG pins for GPIO pins or when the application enters deepsleep mode with all the clocks stopped but provides no means to wake up the device. This is the first time I'm hearing that calling C printf can lock up the device. 

Hi Charles

Here is the response to your questions/comments:

Locked, meaning the LM Flash Programmer cannot flash code, different errors given.  Also, the Keil debugger cannot access the board.

 So, bigger picture, on the older Stellaris boards, many different versions of code work fine on different board variants.  Occasionally in the lab, when updating logic which does not involve pins or sleep mode, we would get the board locking.  We then use the unlock sequence and go back to older code.  The one time I did track it down to a line causing the problem, it was a printf.   There was plenty of stack space for the printf, by the way.

We probably didn't try the same suspect build on another board, because we didn't want to risk bricking another board.

 Newer Tiva boards, some have USB.  Those are not locking up.  Other boards without USB, those are the ones locking up.  We are modifying a EK-TM4C129EXL Crypto Launchpad to be used as a USB interface to the board to unlock.   So, we haven't attempted an unlock yet on the Tiva boards yet.

 On the older Stellaris boards, the unlock sequence typically worked the first time.  Sometimes, it would take a few tries.  Sometimes, it wouldn't work.

 Sleep - We are configuring to support sleep, such as a calls to SysCtlPeripheralSleepEnable() but never have calls to SysCtlSleep or SysCtlDeepSleep to go into sleep.

 JTAG - To check again if we are reconfiguring JTAG pins, would that be checking for calls to GPIOPinTypeGPIOInput and GPIOPinTypeGPIOOutput?   Haven’t found any JTAG pins being reused as GPIO.  I want to make sure we are doing valid checks against the code.  Any other calls to search for?

 Thanks

Best regards,

Jim B

Hi Jim,

Jim Brinkhurst1 said:

So, bigger picture, on the older Stellaris boards, many different versions of code work fine on different board variants.  Occasionally in the lab, when updating logic which does not involve pins or sleep mode, we would get the board locking.  We then use the unlock sequence and go back to older code.  The one time I did track it down to a line causing the problem, it was a printf.   There was plenty of stack space for the printf, by the way.

  I don't have much knowledge about the Stellaris products as they are EOL. We don't have any one who can support the Stellaris products. With that said, the printf causing the device to lockup is limited to the Stellaris MCU, not the Tiva MCU. Is that a correct understanding?

Jim Brinkhurst1 said:

Newer Tiva boards, some have USB.  Those are not locking up.  Other boards without USB, those are the ones locking up.  We are modifying a EK-TM4C129EXL Crypto Launchpad to be used as a USB interface to the board to unlock.   So, we haven't attempted an unlock yet on the Tiva boards yet.

Not sure why you need a LaunchPad to unlock your board. Don't you have an external debug probe that you can plug into the JTAG connector on your board?. Please note that to unlock the device you need to have the JTAG interface. The unlock procedure involves scanning some special sequence of commands to the device through the JTAG interface. 

Please elaborate on the 2 Tiva boards that are locked. What I want to know is that other Tiva boards running the same code are not locked but only these two and they are not locked because of printf. Is that correct?

Jim Brinkhurst1 said:

 Sleep - We are configuring to support sleep, such as a calls to SysCtlPeripheralSleepEnable() but never have calls to SysCtlSleep or SysCtlDeepSleep to go into sleep.

Ok. So at least your Tiva board lockup is not due to clock stopped because of the deepsleep mode. 

Jim Brinkhurst1 said:

 JTAG - To check again if we are reconfiguring JTAG pins, would that be checking for calls to GPIOPinTypeGPIOInput and GPIOPinTypeGPIOOutput?   Haven’t found any JTAG pins being reused as GPIO.  I want to make sure we are doing valid checks against the code.  Any other calls to search for?

See below table. I doubt you re-purpose the PC[3:0] for GPIO because if you do, all of your boards will be locked out and not just 2 Tiva boards.

Hi Charles

Here is the latest update from the customer:

We don't yet know if the Tiva problem is a lockup or not.  Once we attempt an unlock we'll know, then try to track down the cause.

The Stellaris and Tiva manuals are so similar, I assume this lockup cause in the chip is common to both, but okay, Stellaris is EOL.

 On the Tiva boards, the code has a common bootloader, then different application code, so we don't know if it is the common code or not which is causing the problem.

 For the unlock sequence, we have been using the LM Flash programmer tool to do the unlock sequences in the manual.  LM Flash programmer has 4 options (ICDI, Red Probe, Serial, Ethernet).  We use ICDI with our boards with USB.

These two Tiva boards don't have USB, they use the ULink debug adapter.

I asked the testers if they have used the LM Flash programmer with the ULink adapter to the board.  The first one didn't think it works.  Should it?  If not, what is the recommended unlock tool when not using USB?

 BTW, LM Flash programmer tool V1613, not fully Win10 compatible.  Sometimes requires running in administrator mode.  Sometimes crashes a few times, then works.

I was hoping there was a newer version in work.

 Definitely not re-purposing PC[3:0] in Tiva or Stellaris code (same pins on the Stellaris chip).  I searched through the code.

Thanks!

Best regards,

Jim B

Hi Jim,

Jim Brinkhurst1 said:

We don't yet know if the Tiva problem is a lockup or not.  Once we attempt an unlock we'll know, then try to track down the cause.

  Contrary to the original post where it says there are two Tiva boards locked up, now this is not true. So what is problem with the two Tiva boards now? I'm confused now when it was originally stated as lockup and now it is not yet known if lockup or not.

Jim Brinkhurst1 said:

On the Tiva boards, the code has a common bootloader, then different application code, so we don't know if it is the common code or not which is causing the problem.

If not lockup, then what is the problem?

Jim Brinkhurst1 said:

 For the unlock sequence, we have been using the LM Flash programmer tool to do the unlock sequences in the manual.  LM Flash programmer has 4 options (ICDI, Red Probe, Serial, Ethernet).  We use ICDI with our boards with USB.

You can only use the LM flash programmer to unlock the device if the debug probe is ICDI. 

Jim Brinkhurst1 said:

These two Tiva boards don't have USB, they use the ULink debug adapter.

OK. The LM flash programmer only works with ICDI debug probe, not Ulink. By the way, I have no experience with Ulink and will not be able to answer questions regarding Ulink. If you have use Ulink to the debug the target device then it is fine. It is just that the LM flash programmer cannot be used to unlock the device using Ulink debug probe.

Jim Brinkhurst1 said:

I asked the testers if they have used the LM Flash programmer with the ULink adapter to the board.  The first one didn't think it works.  Should it?  If not, what is the recommended unlock tool when not using USB?

If your board is truly locked and you need to unlock then you can also use the XDS100, XDS200 debug probes to unlock them. You will need to use the Uniflash tool to unlock the device. Again, the LM flash programmer only works with the ICDI. For debug probe such as XDS100 or XDS200 you will need to use Uniflash. The Uniflash can be downloaded at https://www.ti.com/tool/UNIFLASH

Jim Brinkhurst1 said:

BTW, LM Flash programmer tool V1613, not fully Win10 compatible.  Sometimes requires running in administrator mode.  Sometimes crashes a few times, then works.

V1613 is the latest version. Please run in Admin mode.

Jim Brinkhurst1 said:

 Definitely not re-purposing PC[3:0] in Tiva or Stellaris code (same pins on the Stellaris chip).  I searched through the code.

So we can rule out the lockup due to re-purposing PC[3:0]

Thanks Charles

I'll pass this on to the customer.

Note, in the initial post (copied again below) they weren't 100% sure it was a lockup issue with the TIVA. 

"We are using the Tiva TM4C129ENCPDT as well as the Stellaris LM3S9U81 microcontrollers.

We've had at least 8 of the Stellaris chips lock up in the past and now we think we have two of our new boards with the Tiva lock up.  Working on getting a USB wired up to try the unlock sequence on the Tiva.

 This is the case where new code is flashed and the chip locks up.  To make sure there is no confusion over what "locked" means, the Tiva and Stellaris manuals have a section called "Recovering a Locked Microcontroller".

Best regards,

Jim B