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.

TMS320F28379D: Problems programming Flash in Get Mode, and debugging in Wait Mode

Part Number: TMS320F28379D


Greetings,

CCS Compiler: TI v18.1.1.LTS

Emulator: Spectrum Digital XDS100v2

I am building a custom board with the TMS320F28379D (176 pin) package. After initially soldering on the board I tested it by verifying the 20-pin JTAG connectivity and then programming the Flash in Get Mode, and everything was testing as expected.

After finishing the rest of the board, I attempted to program and I was having JTAG Connectivity/Integrity issues. After following this guide (), my partner and I have found that the XRSn State is pulsing periodically (approximately every 7milli seconds). This issue occurs whenever Get Mode is selected on the Boot pins and the board is powered on. If I understand correctly, that means the Delfino is booting from what was previously programmed in Flash and is executing in some way.

Power cycling sometimes sets XRSn to be in its normal high state, but an attempt to program results in this:

Flash Fail.docx

Switching the boot mode pins to Wait Mode allows me to program the device with my RAM build configuration. However, when I attempt to debug/"Play" the following is displayed:

C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code.  Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
C28xx_CPU2: GEL Output:
Memory Map Initialization Complete
C28xx_CPU2: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code.  Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
C28xx_CPU1: Error: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 7.0.188.0)
C28xx_CPU1: Unable to determine target status after 20 attempts
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_CPU2: Error: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 7.0.188.0)
C28xx_CPU2: Error: (Error -1135 @ 0x3FEC52) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 7.0.188.0)
C28xx_CPU2: Unable to determine target status after 20 attempts
C28xx_CPU2: Failed to remove the debug state from the target before disconnecting.

We've been having power issues, so we thought it was our onboard supply, but even with a dedicated power supply we still have the same issues. As I mentioned before, the chip on this proto-board has programmed but has now ceased to do so after assembly was finished. I can provide schematics and layout images if necessary.

Best,

Matt