- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A couple of questions -
- You did mention you are using PSoC Creator. Are you exporting your project and then using JTAG?
- Could you please share the TOC2 dump of both of these devices?
- Can you read out the device ID and share it here?
- Can you trace the JTAG communication lines when trying to acquire the device during debug for both of these devices?
Yes, ES does mean Engineering Sample. If I am not wrong, the newer PSoC 6 devices do not have all 0s in their TOC2. There was an issue that bricked the device when the TOC2 was made all 0.
So just wanted to confirm the device by checking the device ID.
Also, can you confirm that programming and debugging the device on SWD works as expected? Which debugger are you using?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the reply.
I used the term JTAG, but meant SWD. I'm using PSoC Creator with a MiniProg4. As I said, I can program the code over SWD ("Debug->Program" in PSoC Creator), but if I choose to debug ("Debug->Debug"), it seems to time-out waiting for the target code to hit a breakpoint in main (that's just a guess/I assume that's what is happening)
So, the SWD wires are connected, since I can program the PSoC chip over the same wires.
Here's some device info (some of the info came from 'cysecuretools'):
First, here's the 'good' chip that we've been using for quite a while/works fine:
Here is the "ES" part:
Here is a hex dump of the ES part's TOC2 data:
EDIT: Here's the hexdump from an ES device "as received" (before I started tweaking it in order to try to get SWD working):
16007c00 fc 01 00 00 20 12 21 01 00 00 00 00 00 00 00 00 .... .!.........
16007c10 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007c90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007ca0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007cb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007cc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007cd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007ce0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007cf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007d90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007da0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007db0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007dc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007dd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007de0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
16007df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 64 ...............d
Thanks again for your response (and any help you can offer on this)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've noticed that the SoC Unique ID (returned with Cy_SysLib_GetUniqueId()) always has "0" for the "year" field of the 64-bit UID (bits [63:57]), for all of our known-ES devices.
Other 'normal' PSoC chips have year values 0x76, 0x77, etc.
I wonder if this is a way to "detect" that I've got an ES part on the board.
It still would be nice to know what *exactly* is different between these parts and production parts.