TM4C123GH6PM: Thread locked

Hi Andre,

 The forum system automatically lock thread after one month. Here is the question in the other thread.

Hi thanks. I opened CCS and tried to add more Devices for each debugger (daisy-chain several):
- XDS100V1 - couldn't add TM4C devices
- XDS100V2 - success to add several TM4C devices
- XDS100V3 - success to add several TM4C devices
- XDS2xx - success to add several TM4C devices
- XDS2xx onboard - success to add several TM4C devices
- ICDI - success to add several TM4C devices
Strange that i can add several devices in CCS using ICDI because i read here e2e.ti.com/.../379659 that it does not support

At the moment i am using linux and under SSH i can connect to the computer where the ICDI is connected and lm4flash my boards individually. My point here is to reduce the number of programmers and still use command line flashing. How can i accomplish that if im stuck with the CCS IDE to configure targets, compile, debug and flash?

I'm not clear with your question. Are you looking for a non-CCS tool, such as an off the shelf CLI tool to program each target individually or in a daisy-chain? If you are looking for a CLI tool then you can use the Uniflash but I'm not sure it is capable to program all targets in daisy-chain. Depending on your question I will need to move your post to the CCS forum group for their expertise in this subject.

Please take a look at the Uniflash wiki page and search for the CLI commands.

 

Hi Charles.

Thanks for the reply.
So my intention is to have 1 programmer in my system and several targets, so daisy chain is the only option as i read (at least for TM4C targets).
My system is composed by a computer running linux, and sometimes i'd want to reflash the targets via the one programmer remotelly. Under linux i understood that i can use CCS but i'd prefer to use a command line tool to select which target i am going to reflash (putting the other targets in bypass mode).

Hi Andre,
Thanks for the clarification. Can you please go through the Uniflash CLI first?

Here in the forum it stated that Uniflash does not support daisy-chaining
e2e.ti.com/.../678443

Hi Andre,
Thanks for the pointer. If our CCS experts already confirm that Uniflash does not support daisy-chaining programming then there is not a TI tool that I'm aware of will do. You will need to search for other non-TI tools with such capability. Sorry, there isn't really anything I can offer here. You can still use Uniflash CLI to individually program your targets if you are looking for a programming tool with CLI.

Please also go to the last reply by Rick Lau in the thread you referenced and see if it helps. e2e.ti.com/.../678443

Hi Andre,

Would it not be just as easy to write Pearl script to control UniFlash from the Linux box? Script will have menu to select the desired configuration from menu to launch UniFlash, send selected output CMD lines for each device. Seemingly if the MCU does not match the device DAP port being called in UniFlash the other devices on the chain should ignore the JTAG connection request.

Hi

I have no idea how to do that and have no skills in Pearl so i won't call it an easy task (at least for me).

Hi Charles.

Well it seems that might solve have solved my issue, although i need more testing.
The dslite.sh can receive a --core argument with the number of the target on the JTAG chain. And it also receives the configuration file. I was able to generate a config file for each target on the chain and insert in via cmd_line along with the dslite command. Example below.
./dslite.sh --config=user_files/configs/tm4c123gh6pm.ccxml --core=0 --verbose --flash --verify user_files/images/blinky.bin,0x0

Now i just need a decent programmer that supports daisy chain to validate this.
I have a Launchxl-RM42 board with me. Its programmer is a XDS100V2 and as i read it supports daisy chain.
Do you know an easy way to connect this programmer with my TM4C boards, removing the RM42 MCU onboard the lauchpad?
www.ti.com/.../spnu612
On its schematics i could only find the 0 Ohm resistors R25 to R33. But these have really small pads and have almost no space so solder wires to an external MCU.

Hi Andre,
I cannot comment about RM42 as I don't support that MCU. You are on your own if you want to modify that RM42 launchpad to support debugging out another targets. You will be the first one doing this as far as I know - using RM42 to debug TM4C.
The easiest solution is to purchase either the XDS100v2 or XDS110 debug probe.
www.ti.com/.../TMDSEMU110-U
www.newark.com/.../78R2896

I will close this thread for now. If you have new questions you can open a new thread. 

It seems the Launchxl onboard XDS100V2 is working in a daisy chain connection.

I removed R25 (TMS), R27 (TDI), R30 (TDO), R32 (TCK), R33 (RESET) and connected an external header for these 5 pins. Connected them to the 2 TM4C123 boards. XDS100V2 TDI connected to 1st TM4C123 TDI, TDO connected to the 2nd TM4C123 TDI and the 2nd TDO connected to XDS100V2 TDO. The rest JTAG pins in parallel.

I created a CCS config ccxml file with XDS100V2 and two TM4C123 targets and executed 2 lines of code. It seems there is no need to check the bypass checkbox on CCS because on dslite the --core flag chooses the MCU order on the chain.

Each one flashed one MCU:

./dslite.sh --config=user_files/configs/xds100v2_tm4c123_1_and_2.ccxml --core=0 --verbose --flash --verify user_files/images/blinky.bin,0x0

./dslite.sh --config=user_files/configs/xds100v2_tm4c123_1_and_2.ccxml --core=1 --verbose --flash --verify user_files/images/blinky.bin,0x0

For now i am only having issues with the reset signal on the XDS100V2 board. It is now resetting the MCUs on the chain. I don't know why. Have to manually press the reset button on each MCU board.

Andre Leitao said:

I have no idea how to do that and have no skills in Pearl so i won't call it an easy task (at least for me).

You will never know what you are capable of until you at least try! After all Linux users should know something about Pearl scripting or switch back to Windows and use simple CMD scripts. I would bet you can pick up Pearl script after installing RPMS and doing some C+ programming. I'm purely an MS guy but have played with Linux in the past and reviewed a few Pearl command scripts.

There is another flash programmer (DFUprog) found in Tivaware library tools folder an Visual Studio C++ project that compiles to exe. You can modify it in VS or perhaps it will support daisy chain with input from a CMD script.

This is becoming off topic. I don't mind trying - i just don't understand and seems complicated and time consuming for the intentions i have.
But why Pearl? why not shell scripting? I've created simple scripts to run simple stuff for repeating tasks or boot tasks.
I am no software guy. I learned what i needed from linux for microcontroller development (firmware. not software) - C, gcc and gdb!
So i stick with for me is simpler - hacking existing hardware to validate a possibility instead of buying expensive tools just for the sake of testing.
BTW - dslite works

Andre Leitao said:

But why Pearl? why not shell scripting?

Always figured Linux shell scripting used a reduced subset of Pearl syntax.  Anyway the idea was to control multiple daisy chain DAP ports access via a central GUI. Otherwise pre-written lines of specific configuration strings sent by the script when selected by a number. It would seem you have exhausted all other possibilities to that desired CCS debug concept, off topic not!  

Have you found the cause of the reset by looking the RESC register?

Hey Charles.

Nop. I tried to connect both the RESET and the TRSTN of the Hercules board to the TM4C RESET but it doesn't work.
The RESET is connected via a push-button, so only works on button press. And te TRSTN pin was not changing value during/after programming.
I'd have to try with a ready-to-buy programmer.

One strange thing about this is that when i flashed the tivaware blink.bin using the dslite - the program started executing after programming. But when i flashed with my application code binary file i'd have to press a reset after programming in order to get the code running...
But when i use the TM4C onboard ICDI via lm4flash i don't need to press any reset button.

Hi,

 I'm a bit unclear. You wrote earlier "It is now resetting the MCUs on the chain. I don't know why. Have to manually press the reset button on each MCU board." I thought you were getting reset when you tried to program based on your statement. Now you said you are trying to connect the RESET/TRSTN from the RM43 to the TM4C123. You need to know that there is no nTRST input to the TM4C123. So connecting TRSTN from the RM42 has no use. I'm not sure which RESET from RM42 you are trying to connect as I don't directly support that MCU. Can you clarify? Are you talking about the RESET from the RM42 MCU? I thought you were trying to use the RM42 board's on-board debug probe (the XDS100), why are you connecting the RM42 MCU's RESET to the TM4C123. 

  Again, I'm not clear if you are having an inadvertent reset to the TM4C123 or not. If this is the case, you need to read the RESC register to find the cause of the reset event.

Similar to the ICDI on tm4c123 evaluation board we have JTAG pins between the programmer and the target we also have a reset pin. I thought i'd need the Reset because somehow the XDS100V2 on hercules board is not restarting the code after flashing. How does the JTAG does the reset with only TMS, TCK, TDI and TDO?

Yes, per JTAG protocol (IEEE 1149) you just need to keep TMS high for at least 5 cycles then the TAP state machine will be reset. The nTRST is an optional input which is not employed in the TM4C123.

Ok. If i don't need the reset to restart the code after programming something is wrong with the hack that i performed.
Or its something to do with the daisy chain. Because with the ICDI on EK-TM4C123GXL the same binary works fine and starts after programming.

Hi Andre,

To best of my knowledge LMFlash, ICDI each perform Soft reset after write finishes. You can find the soft reset code somewhere in (flash.c) found in the utils folder. Good to see you being diligent to make a chain mode work.

Hi Andre,

 Are you making some progress? Can you try some of the options below?

  Do you at least have one the XDS debug probe that you can borrow if you don't have one yourself. This way it is easier to narrow down the problem. Again, I recommend you purchase one. If you insist hacking the RM42 (a device and launchpad that I'm not so familiar with ) then it is not what I will recommend but it is your choice.