Other Parts Discussed in Thread: ISO7220C
We are having trouble with JTAG communications to CPU2 on some TMS320F28377D MCUs. We previously implemented custom circuit boards around the TMS320F29379D processor, but due to issues sourcing these processors we decided on the TMS320F28377D as a replacement. Only half of the cards built up using the TMS320F28377D worked as expected, with the rest displaying the same issue that JTAG communications to CPU2 are unreliable. The JTAG communications to CPU1 do not seem to have any issues connecting, controlling and flashing images on any of these cards.
The only workaround thus far has been to dramatically reduce the JTAG clock speed down to about 20kHz. At higher JTAG clock speeds every attempt to connect to CPU2 with CCS returns error messages (Error -1015 @ 0x0 Device may be locked, Error -1041 @ 0x0 Debug probe reported an error after failing to reset the CPU) which seems to be false as these errors do not occur at very slow JTAG clock speeds.
We power on the cards in WAIT boot mode. Connecting to CPU1 does not indicate any issues. CPU1 remains halted. Then, initial connections to CPU2 gives the Error -1015. Clicking on Retry establishes a connection to CPU2, but indicates Error -1041. CPU2 also remains halted. By reading the User OTP memory section (assumed to contain only 1's from) using the memory browser it seems that as the JTAG clock frequency increases more of the data being read back is corrupt. Reading the TI OTP memory section (known to contain fixed data from factory) also returns corrupted data that differs with each read.
Browsing through the register space also indicates that some reads may be returning corrupted data, e.g. in the image below the CPB_DAT register returns changing values when reading from CPU2, but not when reading from CPU1.
We use CCS V10.4.0.00006 and all packages have been updated to latest available versions. The workspace was ported from CCS V7.1.0.00016 that was used for the initial implementation - this was done to accommodate the product change notice https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/729543/faq-product-change-notice-pcn-20180523001-1-and-pcn-20200115000-2-for-tms320f2837x-and-tms320f2807x-devices.
We have looked at the following to try to narrow down where the issue may be located:
- SPRZ412L Silicon Errata: "INTOSC: VDDOSC Powered Without VDD Can Cause INTOSC Frequency Drift" advisory.
- SPRZ412L Silicon Errata: "Low-Power Modes: Power Down Flash or Maintain Minimum Device Activity" advisory, as our issue seemed to be similar to the issue discussed in https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/733522/tms320f28379d-delfino-tms320f28379-cpu2-not-reliably-flashed-via-jtag-interface-without-severely-slowing-down-clock-from-190mhz-to-25mhz as we also program our own secondary bootloader to flash. However, even with the valid secondary bootloader programmed on the cards, the JTAG clock needs to be set to 20kHz to allow debugging CPU2 code from RAM.
- Using SCI boot mode we are able to program the Blinky_LED test applications to CPU1 and CPU2. Power-cycling the cards into GET/FLASH mode results in both CPU applications running as expected.
- We worked through https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html and associated issues for the previously mentioned error codes.
- All boards have been xray'ed to ensure proper connections on the BGA. Supplies and decoupling have been double-checked to comply with data manual specifications. Components and devices between working and non-working cards have also been verified to be the same.
- All cards have an onboard isolated FTDI USB-to-XDS100v2 JTAG as typically used on TI controlCard daughter boards. Corresponding JTAG signals of working and non-working cards have no apparent differences.
It seems rather odd that CPU1 does not have any issues, but CPU2 has issues for some cards.
Can you recommend any further hardware/software debugging actions?
