Debugger infrastructure and autodiscovery

[plowhank]

According to the QuickLogic EOS S3 documentation and standard practices in SoC design, there is typically a unique device identifier or SoC ID that can be read from a specific memory-mapped register. However, the EOS S3 Technical Reference Manual does not explicitly list such a SoC ID in an easily accessible location. You may want to:
- Check the Default ROM Board Base Address (`0xe00ff000`) for the device specific PID or other identifiers.
- Review the TRM Debug Infrastructure section for references to ID-related registers.
- If the base PID is the ARM default, that may indicate a lack of appropriate SoC-specific customization, as noted in your observations.

[charliebrown33]

Thanks for the detailed analysis—you're right on several points, and to answer your questions: yes, the EOS S3 has a unique SoC identifier accessible via the SYSCTRL block, and a per-instance unique ID is available through the eFuse registers at 0x4002_7000.
basketball stars

[designdev]

Typically, SoC chips will have a read-only memory (ROM) area that contains the chip ID. You can check to see if there is an area in the technical documentation (TRM) or through the system registers to determine the SoC ID. If there is no specific information in the TRM, you can try searching in the support documents from QuickLogic or ask their technical support directly.

Some SoCs may have registers that contain information unique to the chip, which may be located in fuse registers or other memory areas. You should refer to the TRM to find out what these registers are. If you do not see the information, you can also ask QuickLogic for confirmation.

If you have additional questions or need more specific assistance, let me know!

Thanks for the info! Do you know if QuickLogic’s EOS S3 has a specific register for the chip ID, or where exactly to find it in the TRM?

[annakame]

Thanks for the explanation about SoC ID and debug infrastructure — super helpful when I'm debugging on the EOS-S3!
mapquest driving directions

[Thalassa]

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.
slope
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.

have any information?