Debugger infrastructure and autodiscovery

[oqin]

Hello,

Just to play with new platform, I bought a "Thing Plus – QuickLogic EOS S3". As soon as it arrived, I connected it to my SWD debugger and tried to enumerate it.

As intended by ARM debug infrastructure, it enumerates well, but there are a few overlooks (implementation bugs) that could probably be fixed in future HW revisions:

• DP IDR is 0x2ba01477, which means it implements DPv1 (See IHI0031G B2.2.5), this is perfectly valid, then target identification should be done through Base ROM Table (See ARM IHI0031G D1.3.1),
• Nonetheless, SW-DP TargetID register (Bank 2, address 0x4) is implemented and contains 0xf0000041, which decodes to STMicro's Jedec ID (Cont=0, ID=0x20, i.e. idcode[11:0]=0x041) (but quite close to V3 semi's ID (Cont=1, ID=0x41, i.e. idcode[11:0]=0x183) (bug ? see below)),
• Base ROM Table (the one at 0xe00ff000) is supposed to contain a PID matching the target device. It contains PID=00000004000bb4c4. This is an ARM identifier (probably the default in CM4 source code), but there should have been a QuickLogic ID there.

About Jedec IDs, in EOS S3 TRM (r1.01a), page 34, in table 3-2, there are various component IDs and decoded Jedec IDs, but you seem to totally forget about Jedec continuation code (bits 11-8 of a JTAG IDCODE or bits 3:0 of PID4 -- See ARM's IHI0029E B2.2.2). This seems to be confirmed by TargetID above, where we are missing the 0x1 continuation code and have shifted ID.

Now the questions I could not answer with the TRM:

• Is there a SoC ID somewhere in a read-only memory-readable region that could confirm this is an EOS-S3 chip that i'm actually talking to ?
• Is there a "Die-ID" or other per-instance unique ID register mapped somewhere ? Maybe in fuses ?

Thanks.

[spurgenotion]

Have any update about this issue?

slice master