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.

CCS/TM4C123GH6PM: Trouble Programming Custom PCB using CCS and Dev Board

Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: UNIFLASH, EK-TM4C123GXL

Tool/software: Code Composer Studio

I'm an ECE student at the University involved with a Research Lab and we've recently adopted the TM4C123GH6PM processor for our PCB designs. We're currently encountering issues with programming our first boards. Right now we're trying to use the TIVA dev boards to program our board via the JTAG. Below, I've posted images of the schematic I'm working on, the error from CCS when we attempt to flash the boards, the JTAG schematic from the JTAG programming guide(section 4.4) that we modeled our schematic after ,and the instructions we followed to use the dev board as a programmer(secion 4.5) .

We're kind of just stumped on what else to check. It seems like we've followed most of the documentation on designing boards using the TM4C so we currently don't have the impression that's it's inherently a design issue. The only thing we've soldered to the board is the necessary components to program the MCU(decoupling caps, reset button, and headers) ,and we're powering it with 3V3 directly(without the LDO).  We've verified that the all the JTAG lines are pulled to the correct voltages and that the MCU is receiving 3V3. Any additional advice would be greatly appreciated.  

  • It just occurred to me that that schematic I posted turned out like garbage when I posted it here. 

    Here's the PDF I generated from Altium.CANtoUSB_TIVA.pdf

  • Hi,

    Thanks for such detailed post. Unfortunately the legacy ICDI interface of the TM4C123 launchpad is not well furnished with diagnostics, therefore it becomes very difficult to pinpoint the exact root cause of the problem.

    From the schematics, however, I can see that you added pull up resistors to the target board - although we don't recommend doing this for a typical JTAG interface when using XDS-class debug probes, these resistors are surely furnished with the TM4C Launchpad boards. That may be one of the issues: you are, in fact, associating two 10kΩ resistors in parallel, which becomes a 5kΩ pull up - perhaps too strong for the signals.

    Another detail is to double-check all connections between the launchpad and the board - also, make sure they are as small as possible to avoid delays and interferences on the JTAG signaling.

    If you are still unable to connect, you will have to check the HW in your custom board: power, noise, connections, etc.

    Hope this helps,
    Rafael
  • Hey Rafael,

    Thanks for the response but it seems to not be an issue of the dev board's pull up resistors. We tried with and without to no avail. It seems that the the pull up resistors that have access to the JTAG headers on the dev board are only pulled when the jumper that powers the development MCU is connected. We remove this jumper to program the custom board.

     

    We've now got some breakout boards that we've soldered a one of our TIVAs to. We thought it may be an issue with the preferred practices for unused signals from the manual so right now we're trying to program a bare mcu that we're just powering directly using the dev board. 

    We're also not sure about the JTAG connection length because another member was able to program another devboard with the same length of jumper wire.

  • Hi,

    Thanks for the clarification on the jumper and the resistors.

    Were you able to program the other devices on the breakout boards?

    The length of the connections is something that may vary widely depending on the boundary conditions. In general it works very well, especially for such low speed communications of the ICDI, but given this Debug Probe does not provide any other diagnostics, a slight glitch or delay is enough to completely kill the communications.

    You can also plug an oscilloscope and try to compare the waveforms with what I did in the post below. Although it is a different device, it may give clues as to what to expect.
    e2e.ti.com/.../2442314

    Looking at yoru schematics diagram I don't really see any issue with the JTAG itself, but that makes me wonder: is the device itself powered up properly?

    Apart from this, unfortunately I am running out of ideas. I will definitely report back in case I find something else relevant.

    Regards,
    Rafael
  •  Just to give an update on what we're trying next. One of our members suggested that the launchpads couldn't reliably program via JTAG so we've got obtained some XDS100v2 debug probes from our school lab techs.

    We'll update on any progress we make with this.

    Also here's a screenshot of the TDO line with no pull up resistor. This returned a time out error where as adding the pull down returned the original error posted.

  • Next update:

    We tried using the XDS to no avail and verified the connection which succeeded.

    This is the error we received when trying to flash. 

    CS_DAP_0: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.27.9)

    And based on the succeeded connnection test and section 6.1 of the JTAG manual, I'm assuming this isolates it from being a power issue.

    What does it mean by the device may have not initialized itself?

  • Hi,

    As you said, the error message you showed exposes a problem with the core itself and not with the physical connections. This error is explained in detail at the Debugging JTAG page below (just search for the error code).

    software-dl.ti.com/.../ccs_debugging_jtag_connectivity_issues.html

    In this case, I would try the procedure to unlock the device. A reference is shown at:
    e2e.ti.com/.../476011

    Hope this helps,
    Rafael
  • I'm getting this error when attempting to use both an XDS or ICDI to unlock the MCU. From the JTAG guide, it seems like I have to install a separate set of software to use the unlock feature. The issues is there I can't seem to find said software. Is this the case?

  • And attached to that is this issue when I try to run the command specified in the JTAG manual for using the unlock feature on Uniflash using the XDS100v2

  • Hi,

    I don't recognize the "Module Closed" error message, but it seems to be the connection was never established (Uniflash has a more limited error reporting mechanism when compared to a full blown CCS).

    In your last post, the parameter is incorrect in your last command invocation - it should be @xds100v2 not @xds100vs2. If the probe is still unable to unlock the device, I would definitely check its power/clock circuitry.

    At this point I am running out of ideas. The major blocking issue is the unresponsive core, but from a JTAG standpoint no further diagnostics can be performed. At any rate, I will see if the device experts may have any further comments.

    Regards,
    Rafael
  • I am unable to read the image of the schematic you posted. Would you please verify that RST- (pin 38) is pulled high?

    If the device is a new, never programmed device, it should not require to be unlocked. If the device is locked, then using the EK-TM4C123GXL Launchpad as the scan controller you can use LM-Flash Programmer to unlock the part.

  • Hey Bob,

    Here's the pdf generated from Altium. I also posted it in another comment.

    We found it kind of weird for it to be locked out of the box ,but we're not sure what in our schematic is causing an instant lock. We also tried soldering our "locked" mcus to the launchpad directly and it programmed so there's some hardware error we're doing both on the breakout and the pcb that's causing the core to be unresponsive. We've verified that reset is pulled high as it should be. Is it possible that we require an external oscillator? 

    Onto the reset, we've held the target under reset while trying to program and it outputs a separate error. So we deduced it wasn't an issue with the reset.

    7774.CANtoUSB_TIVA.pdf

  • I do not see anything wrong in the schematic. I even verified that the debugger will connect without a crystal between OSC0 and OSC1. It did with no problems. Could there be a mismatch between schematic and layout?
  • So it seems the code I've been trying to flash on the mcu configures the TIVA to use the external clock source that I based on the example code that comes with the TivaWare library. Since we don't have an external oscillator, I can assume this would cause the core to be unresponsive if this code were to get on target.

    My question is, would this cause an immediate lock or would I still be able to program the mcu at least once before locking. I tried running the unlocking sequence via the LM Flash program ,but the core still remained unresponsive.

     //set system clock to 16MHZ
        SysCtlClockSet(SYSCTL_SYSDIV_1 |
                       SYSCTL_USE_OSC  |
                       SYSCTL_OSC_MAIN |
                       SYSCTL_XTAL_16MHZ);

    I haven't had the chance to try this out yet,but I'm probably going to desolder the external crystal from one of our launchpads and see if it has the same behavior as what we see on our PCB.

    I just want to validate if this thought process is correct. That if the code we flash onto the target effectively removes its clock source, would this cause it to be unresponsive mid programming as opposed to letting us program at least once before locking or if not having a clock effectively would cause a core "lock".

  • The initial programming would complete. When the part is reset and allowed to run, either by the emulator or by powering off and then on again, the code would run and enable a non-existent clock. From that point, I don't think you will be able to connect with an emulator to erase the part.
  • So I removed the external oscillator from the launchpad and it's failing to program in the same way. I'm going to rewrite the code to use the internal oscillator and see what happens. By external, I'm referring to MOSC.
  • Alright, problem finally resolved.

    So in effect we locked the cores by running the external oscillator code. 

    None of our PCBs, had the MOSC which the launchpad example code relies on.

    I'm assuming how CCS works is that it flashed the code and when it went to verify, since this 

    code locked the core.

    We were  able to remedy this by unlocking the core and flashing code that guaranteed the use of the internal oscillator.

  • Hi,

    Thanks for reporting back your findings. They will be very helpful for other developers in the future.

    Regards,
    Rafael