Hi,
I and my team are running into programming issues, using XDS110 Debug Probe and some target hardware developed with TMS320F280037. Using Code Composer Studio 12.2.0 on a Windows 10 Enterprise system, 64 bit. The XCIN32/XCOUT32 pins are connected to a 20MHZ crystal with 16pF loading on each leg. VDDA, VDAC and VDDIO are connected to 3.3V. VDD is connected simply to a bank of capacitors for regulating the internal 1.2V supply.
The two Boot Mode pins are pulled up with 4.7k resistors to the 3.3V supply rail.
JTAG connections are exposed to 10 pin header via traces approx 1-2" long. No pullups/pulldowns except for TMS pulled up 2.2k to 3.3V.
Power supply is stable, reset is stable.
Here is a scope shot of TDI from successful programming (also demonstrating voltage and signal quality):
When programming fails, TDI may just stay low or may look the same as above.
One of the XDS110's seems to always get Error -6311 "PRSC module failed to write to a register. (Emulation package 9.10.0.00080)
One of the XDS110's seems to work 95% of the time, so I'm not going to address that for now.
One of the XDS110's seems to work about 40% of the time. One common error is "IcePick_C_0: Error connecting to the target: (Error -2131 @ 0x0): Unable to access device register. 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 9.10.0.00080)" This manifestation of failure is also typically accompanied by an ICEPICK error. In some cases, the "Test Connection" feature in the target configuration view has a successful JTAG scan chain but it fails to program. More often it fails completely as well.
Another common error is "Trouble Writing Memory Block at <varies>" Error -1156 @ 0xC000: Device may be operating in low-power mode. Do you want to bring it out of this mode? Choose 'Yes' to force the device to wake up and retry the operation. Choose 'No' to retry the operation without waking the device. (Emulation package 9.10.0.00080)."
The console output for this low power error can look like this:
C28xx_CPU1: GEL Output: RAM initialization done C28xx_CPU1: GEL Output: Memory Map Initialization Complete C28xx_CPU1: GEL Output: ... DCSM Initialization Start ... C28xx_CPU1: GEL Output: ... DCSM Initialization Done ... C28xx_CPU1: Trouble Writing Memory Block at 0x5fb00 on Page 0 of Length 0x2: (Error -1156 @ 0x800) Device may be operating in low-power mode. Do you want to bring it out of this mode? Choose 'Yes' to force the device to wake up and retry the operation. Choose 'No' to retry the operation without waking the device. (Emulation package 9.10.0.00080) C28xx_CPU1: Error: (Error -2134 @ 0x0) Unable to control device execution state. 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 9.10.0.00080) C28xx_CPU1: Error occurred during flash operation: Target failed to write 0x05FB00@Program C28xx_CPU1: JTAG Communication Error: (Error -1135 @ 0x3FDBA4) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 9.10.0.00080) C28xx_CPU1: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging C28xx_CPU1: Error occurred during flash operation: Could not read 0x0005F800@Data: target is not connected C28xx_CPU1: Error occurred during flash operation: Could not write 0x0005F800@Data: target is not connected C28xx_CPU1: Error occurred during flash operation: Could not read 0x0700B0@Program: target is not connected C28xx_CPU1: Error occurred during flash operation: Could not write 0x05FB00@Program: target is not connected C28xx_CPU1: Error occurred during flash operation: Could not write 0x0005F800@Data: target is not connected C28xx_CPU1: Error initializing flash programming: Interface returned from dll, but flash is not available on this device.
Things that have seemed to work inconsistently sometimes in the past are
A) Turn power off and wait for it to completely bleed down and unplug programmer.
B) Blow away the .ccxml file and rebuild it from scratch
C) Using cJTAG 2 pin rather than SWD & cJTAG disabled.
I've tried adding pullups to the other jtag lines and that did not seem to help. Would using the XDS200 offer more signal tolerance and a higher success rate? Would modifying the Boot Mode pins make it more reliable? Anything else stand out to try or investigate?
Many thanks in advance.
[Update: This afternoon I've had trouble getting any of the programmers to fail with 2 pin cJTAG turned off. The one repeating failure I was experiencing I ended by removing power and shorting power to ground to bleed off voltage. When I re-enabled 2 pin cJTAG, then one of the XDS100 failed consistently with PRSC failure as noted above, one worked consistently, and one failed intermittently with the Error -2131. I'll switch to disabling the 2 pin cJTAG (which had seemed to make them all work yesterday) and just use the full standard JTAG on the 10 pin connector for now as I continue testing.]
[Update 2: I've since (with cJTAG disabled) been able to get the XDS110's to fail consistently with Error -2131. The micro seems to be in reset since an output gpio was in hi-z resulting in an LED to stay on. Power cycling the board, restarting the computer, swapping XDS's didn't fix it. Only when I shorted the powered 3.3v rail to ground briefly did the aforementioned LED go out (mcu restored to controlling that output) and the mcu was programmable successfully (multiple times, indefinitely by any XDS). It seems like if I leave cJTAG disabled and I short the power supply if I ever get into that weird state, then I should be able to recover... will update the post if I run into this again.]
[Update 3: The latest cycle of failures also showed a simultaneous symptom an endless loop of hello world messages coming out the debug uart port, messages which are transmitted upon completion of a command response. So there may be a firmware component to some of these issues? After pulling the microcontroller reset to ground, it snapped the microcontroller out of that loop, but it was still unable to be programmed. When I briefly shorted the 3.3v supply to ground, the mcu went into its fetal position (gpio high impedance as shown by my LED lighting up) and I was able to program the mcu.]
