New PSoC6 batch - “ES” label - can program over JTAG but cannot DEBUG over JTAG

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
paulbart1234
Level 2
Level 2
5 questions asked 5 sign-ins 5 replies posted

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?

0 Likes
3 Replies
wisc_ece353
Level 3
Level 3
10 replies posted First question asked 10 sign-ins

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?

 

0 Likes

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:

Label: CY8C6247BZI-D54
Chip ID: Silicon : 0xe206, Family: 0x100, Rev: 0x24 (B3)
Flash Boot version: 1.20.1.45

Here is the "ES" part:

Label: CY8C6247BZI-D54ES3
Chip ID: Silicon : 0xe206, Family: 0x100, Rev: 0x22 (B1)
Flash Boot version: 1.0.1.20

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
​



the same region on the original (non-ES) part is all ZEROs.

Thanks again for your response (and any help you can offer on this)
0 Likes

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.

 

0 Likes