Hello -
I’ve been using the CY8C6247BZI-D54 in a project for a while. My code loads/runs/I can debug it (using PSoC Creator) just fine.
We just got new boards in with a new batch of chips. I can load code over JTAG, but can’t debug (it gives some sort of a timeout error).
I ran across this article (https://community.infineon.com/t5/Knowledge-Base-Articles/Configuring-the-PSoC-6-MCU-Startup-Time-fr...), and thought maybe I could adjust the “listen window” for JTAG connections using a TOC2 header.
NOTE: my current project does NOT have a TOC2 header.
I decided to dump the memory at SFLASH address 0x16007c00, and was surprised to find a TOC2 header there already. I went back to an old board/device (several old boards), and see that the region is all zeros (as expected).
So, it’s only the new device that seems to have a preprogrammed TOC2 header. I checked a second board from the new batch, and it has the same. It also cannot be debugged over JTAG.
I noticed that the part number on the new chips is CY8C6247BZI-D54ES3 (“ES3” suffix). Is that “Engineering Sample” (datasheet part number guide makes me think that could be it)
I don’t know the source of these chips - given supply chain issues, I suppose it could have come from anywhere.
I tried to ZERO-out the TOC2 section on the new chip, and ended up with a “brick” (no longer executed my code). The same happened when I corrupted the CRC (in hopes of it using defaults).
Luckily, I was still able to reprogram with JTAG, so after restoring the TOC2 section in SFLASH, the board was recovered (but I still can’t JTAG debug).
NOTE that the TOC2 header that is pre-programmed in these devices has a valid “magic” and CRC, but the “TOC2_FLAGS” value is “0x00000000” (which doesn’t match what the “defaults” are documented to be for this chip, and could explain the inability to debug over JTAG.
Maybe I can write a ‘good’ value there, and it will enable JTAG debug? I’m worried that I may end up making a brick that can no longer be programmed over JTAG.
Thoughts?
