• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 1788 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C1294NCPDT - No longer able to program

Jacob Perrin
Prodigy 30 points
Other Parts Discussed in Thread: TM4C1294NCPDT, SEGGER

Hello,

My team has created a custom PCB on which we have a TM4C1294NCPDT MCU which we program using a JTAG interface. Initially, my team was able to program the MCU with simple "blinky" programs without a problem. However, after connecting a CC3000 breakout module and programming some exponentially more complex code (intended to test the wifi functionality) we are no longer able to program the processor. Attempting to connect via a Segger JLink program gives the following output:

C:\Program Files (x86)\SEGGER\JLink_V502k>JLink.exe
SEGGER J-Link Commander V5.02k ('?' for help)
Compiled Nov 13 2015 18:22:59
DLL version V5.02k, compiled Nov 13 2015 18:22:26
Firmware: J-Link Lite-Cortex-M V8 compiled Aug 20 2015 17:57:19
Hardware: V8.00
S/N: 518007506
Feature(s): GDB
Emulator has Trace capability
VTarget = 3.293V
Info: Found SWD-DP with ID 0x2BA01477
****** Error: Cortex-A/R check: Communication error when trying to read IDR of A
P[0].
Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
Info: Found SWD-DP with ID 0x2BA01477
****** Error: Cortex-A/R check: Communication error when trying to read IDR of A
P[0].
Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
No devices found on JTAG chain. Trying to find device on SWD.
Info: Found SWD-DP with ID 0x2BA01477
****** Error: Cortex-A/R check: Communication error when trying to read IDR of A
P[0].
Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
Info: Found SWD-DP with ID 0x2BA01477
****** Error: Cortex-A/R check: Communication error when trying to read IDR of A
P[0].
Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
No device found on SWD.
Failed to identify target. Trying again with slow (4 kHz) speed.
Info: TotalIRLen = 4, IRPrint = 0x01
****** Error: Could not power up debug port: Control/Status register reads 00000
F03
No devices found on JTAG chain. Trying to find device on SWD.
Info: Found SWD-DP with ID 0x2BA01477
****** Error: Cortex-A/R check: Communication error when trying to read IDR of A
P[0].
Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
Info: Found SWD-DP with ID 0x2BA01477
****** Error: Cortex-A/R check: Communication error when trying to read IDR of A
P[0].
Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
No device found on SWD.
No device found at all. Selecting JTAG as default target interface.
J-Link>

Additionally, we have attempted to "unlock" the processor with the LM Flash Programmer's functionality. This, too, did not succeed.

We are really stuck as to what went wrong and where to go next. We have a limited supply of processors, and they seem to be on backorder by most distributors. It would seem that, if we were to try to program another processor, this would result in the same (fatal?) condition. As such, we would rather figure out what is going wrong and how to fix it before trying to program another processor.

Any help that could be provided would be invaluable.

Thank you!

  • 0
    TI__Guru**** 244400 points
    Hello Jacob

    Why is it showing the message for Cortex A/R connect core?

    The good thing is that the Scan Chain is giving the value of 0x2BA01477 which is the Cortex M4 IDCODE and shows that the CPU is not under reset. To be able to backtrace on the "exponentially" complex program the following post with some known causes on lockout may aid your debug.

    e2e.ti.com/.../374640

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 30 points

    Amit,

    Thanks for your help.

    I have no idea why it claims to be looking for a Cortex A/R, but as you can see further above, the firmware is that of  "J-Link Lite-Cortex-M". This utility is used by our team solely for the purpose of assurance of proper JTAG communication.

    One thing I noticed after looking at that page and researching further was that the errata states that the 4.89k Ethernet PHY Bias RES is necessary whether or not you are using the Ethernet. As such, we have soldered on a 4.7k 10% resistor as suggested by page 24 of the errata. This, however, did not fix our problem.

    I have attached a zip file containing the Eagle files containing our schematic.

    Is this almost assuredly a lockout issue? If so, could a malfunctioning clock cause the appearance of such a lockout? The most recent code we uploaded was the first to use an external clock, the 25 MHz clock, so that might be related to the issue?

    Police Body Cam.zip and layout for reference.

  • 0 in reply to Jacob Perrin
    TI__Guru**** 244400 points
    Hello Jacob,

    Can you check if the Crystal is oscillating? Also if possible please do share the Clock Configuration API that was called in the Application to use the 25MHz crystal?

    Regards
    Amit
  • 0
    Guru 47900 points

    Jacob Perrin said:
    after connecting a CC3000 breakout module and programming some exponentially more complex code ...

    Pardon - but that "exponential violation" of KISS - lands many in your plight!   One small step for man (whether exiting a capsule or adding code) might prevent - or at  minimum - signal exactly when (and where) your code "broke."

    Your writing reveals the connection of a CC3000 module - yet NOT that you've (subsequently) removed it.   In conditions as you post - everything is suspect - you must test your board alone - minus any/all external connects.   (i.e. limit your field of battle)

    Have you tried to reload your "blinky" program?   Reload of the failing program (we're told that's more complex) makes no sense at this time.

    The ground between J-Link and your board must be sound (and tested) and you MUST use (external) pull-up resistors upon each JTAG line.  (I'm not interested in debating this)   Trace lengths of those JTAG signals should be well matched, short and direct.

    Power to your board must be adequate - properly decoupled - and should be monitored under "live" programming conditions...

  • 0 in reply to Amit Ashara
    Prodigy 30 points

    Amit,

    We found a small issue with the schematic regarding the clock, which has since been fixed. After performing this modification, we are now able to use the LM Flash programmer to "Unlock" the device. However, after performing this procedure, we are still unable to program the processor. This seems to be progress though!

    The function call used to direct the clock is as follows:

    g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                             SYSCTL_OSC_MAIN |
                                             SYSCTL_USE_PLL |
                                             SYSCTL_CFG_VCO_480), SYSCLOCK_RATE_HZ);
    From what I understand, this is the correct call for the TM4C129 platform.
    Thanks again!
  • 0 in reply to Jacob Perrin
    TI__Guru**** 244400 points
    Hello Jacob,

    The Clock Configuration function is correct for TM4C129x device and I would assume that the SYSCLOCK_RATE_HZ was defined as 120000000.

    Can you please describe the issue with the schematic viz-a-viz the clock? Also if the device is still not programmable then we cannot be sure if the device was "unlocked".

    Can you please check if the Main Osc is oscillating?

    Regards
    Amit