This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I've assigned your post to the subject matter expert, but due to US Holiday, please expect our response by the end of day Monday.
Best,
Matthew
Ada,
I think this may more a function of the 1kOhm pulldown (and its tolerance) on TRSTn than the C2000. Can you advise which debug probe the customer is using to connect to the device, XDS100, XDS110, XDS200, etc? I think a weaker PD may help here.
Another possibility would be to use "Wait Boot" as shown below to see if this has any effect on the "bad" devices.
Best,
Matthew
Ada,
Thanks for the additional information. Is it possible to try a weaker(larger resistor) PD on TRSTn to see if it helps resolve the issue? Perhaps 2.2kOhm?
Can you comment on the boot mode pins from above and their configuration on your PCB?
Best,
Matthew
We don't have this kind of failed unit at this moment, only keep 2pcs C2000 on our hand for your analysis, checked the date code, found this issue mainly
focus on the date code:2128, only get a few from other date code.
Ada,
Can you share the connection for GPIO34 in your design? This will help me know the boot mode of the device as it powers up.
Best,
Matthew
The Boot mode pins on THC board are GPIO34 and GPIO37 and both are pulled high with 100K ohm resistors to 3.3V.
Ada,
Thanks for the additional information, I need to look at the GET_MODE boot function a bit more, but it shouldn't be effecting programmation differently.
If you have future issues/devices I would look at the TRSTn pin when the emulator is attempting to connect. As I mentioned the 1k is a stronger PD than we recommend in the DS(2.2k), so the emulator pod may have issues driving this high to initiate the connection.
Best,
Matthew