TM4C123GXL debugging fail after firmware upgrade to version 12630

Hello user1890138

First of all a Device Firmware Upgrade is not required on the LaunchPads. You can program the main controller means that the JTAG in essence of basic program and read checks is fine. But it would be difficult to tell why debug fails after a few steps. You cannot revert the firmware.

Regards
Amit

Hi Amit,  

Might a "missing" or mistaken "start-up" file prove a likely suspect when one cannot, "reach main()?"

Also - does this not have the "ring" of, "Poster's OWN Project?"    Simple clear of the device - followed by faithful, factory program "blinky" may restore or add needed details...

Hello cb1

It may be the case but the poster's report of the same working on the other launchpad may prove otherwise. Of course the gammit of issues could be larger such as a failed/damaged crystal, etc,

Regards
Amit

Hi Amit,
I don't believe that we can "count upon" both of poster's boards containing the "identical code."

Hello cb1,

Well only the poster can tell us that. But agreed, that we do need to know more than beyond the Firmware Upgrade.

Regards
Amit

There is one thing you could try in CCS. There is a firmware update mechanism in CCS that might do the trick. To use it you will need to launch a debug session without connecting to the device. To do that you can open the target configuration view from the view menu and then right click on your .ccxml file and select to launch a debug session. Then go to the Tools menu and select On-chip Flash. If you scroll down to the bottom this is a button to update the firmware.

I have not tried this out as I do not have a board that has a newer version of the firmware that is in CCS.

Regards,
John

Hello John,

Are you referring to the newer ICDI firmware for newly launch pads? If that is the case I would not recommend it.

Regards
Amit

Thank you for your replies.
My problems starts with using CCSv6 and lm4flash under linux (after few day debugging fails)...I don't know if some of this tools can automatickly upgrade firmware. After it I found, that debuging do not work properly under windows too...so I upgraded firmware by the lmflash.
Now I have three boards:
1. used under linux and after problems I upgraded firmware by windows lmflash (1613) - not work
2. used with lm4flash under linux, but not upgraded by windows lmflash - not work!
3. original board used only under windows - works...at the present:)

I can provide more informations about the firmware, but I do not know how read the debugger firmware version:(

Same other informations about the bug:
Debugging stops on instruction BX changing instruction set to thumb - after this instruction debugger reports bad PC address and can't read data from uP, BUT program works afrer RUN command (even debugging offer bad data:( ).

Regards
Jan

Hello Jan,

The DFU when upgraded would have gone to the latest version (assuming DFU happened correctly). My initial suspicion was that there would be some corruption of a memory location causing the ICDI not to work as expected. But after a FW upgrade at least it should work one time.

Since it is not clear what is the source of the DFU corruption, I would advise using a 3rd party debugger like XDS.

Regards
Amit

user1890138 said:

Same other informations about the bug:
Debugging stops on instruction BX changing instruction set to thumb - after this instruction debugger reports bad PC address and can't read data from uP, BUT program works afrer RUN command (even debugging offer bad data:( ).

Maybe I have misunderstood, but why the attempt to change "instruction set to thumb"?

The Cortex-M4F CPU in the TM4C123 device only supports instructions in thumb mode, and will crash if attempt to execute ARM mode instructions.

Hello Chester,

Does not explain why another board with the same image is working?

Regards
Amit

Hello,
thank you for your time and answers.
Problem was prety simple. One of my collegues changes my demoboard and new board has our hardware problem - programming lines was connected with other tiva processor - so programming worked, but debugging fail after few instructions. Second board witch I have tested had same problem:-).

Regards
Jan

Hello Jan,

At this point my debug emphasis would be on the end target code. Also does the target code debug well with a off the shelf debugger like XDS100?

Regards
Amit

We do not have any other debugger...we use modified TM4123GLX as debugger (normally our lab disconnects PCB lines to second uP and add connector for our hardware)...this modification caused the problem, because lab forgotten disconnect the PCB lines on same boards. That is why the programming worked (both processors were programmed), but debug does not work (data from processors were not same -> comm error).

Everything about your debugger is ok ;)

Thank you
Jan

Hello Jan

Thanks for confirming the issue and it's root cause.

Regards
Amit