Detect Device with WOL enabled

[StMi_4761721]

Is there a way to confirm whether the device is cannot be reprogrammed due to WOL being enabled.   Here is the situation.   We have boards using the CY8C5868AXI-LP035.   A recent build of these boards will not program either with JTAG or SWD.      The parts appear dead with no activity on TDO,  the pin appears to just be floating.  The devices have white  paint dots near pin 1.   The assembler showed photos that the parts arrived that way.   Some similar parts have worked fine.  However, part way through the tray, the devices appear dead.   These are old stock parts that have been in their inventory for three years.    Chip markings are shown below.  

I am not interested in what is programmed into these parts.  I am also not interested in defeating any security feature.   However, I am interested in any way to confirm that the parts are WOL enabled.    If I could do that, then I could have the assembler sort boards and replace chips that were locked.

The datasheet says:   "The WOL can be read out via SWD port to electrically identify protected parts."  However, it does not give any details.   I have the MiniProg3 and I loaded the latest programmer release.    Can that be used to read this register?   

Is there a different tool that would tell me the protection status of an installed PSoC?

Again, I don't want to see the code in any pre-programmed parts.   All I want to do is completely erase and reprogram.   If WOL is set, I would like to be able to detect that so that the parts can be replaced and we can move forward.

Thanks. 

CY8C5868AXI

LP035  TWN1731

A04    630459

[Len_CONSULTRON]

stmi,

I'm not sure I have a definitive answer.

There is a CPU register that reflects the WOL status.

However IF the WOL is set then you cannot get access to this register from the SWD (Debugger/Programming) interface.   The register should be able to be accessed by the CPU when running the application.

Unless Cypress provided a special "SWD at reset when wOL set" mode, Cypress may be assuming if the SWD doesn't properly respond, it is ASSUMED the WOL is set.

Len

[StMi_4761721]

Thank you for the suggestions.  Because the parts have either unknown firmware or perhaps no firmware,  I cannot read the register using the CPU.    I understand that Cypress may not want to broadcast that the part is WOL.   Since if they made it obvious, then people would think the chip contains code worth stealing. 

However, it is important to our company to know whether these are locked or bad devices.    The assembler did a prototype run of four boards of a new design.  Each board has two PSoCs.   All four are dead.   It could be locked silicon or it could be damaged silicon.   If the parts are damaged, then we need to know that to look for either test procedure problems or design problems.

[Len_CONSULTRON]

stmi,

You mentioned this build was a 'prototype' run of four boards.  

Have you run other 'prototype' runs on this rev of PCB in the past?

If so, have they successfully programmed?

You mentioned there are two PSoCs per PCB.  Are both PSoCs incapable of being programmed?

Len

[StMi_4761721]

Hi Len,

Let me explain some details.  The boards have been built before.  Probably about 6 boards.  These were sent un-programmed to the HW design engineer.  He tested them, programmed them and then distributed them to the software design team.  This prototype build of four boards were for customer samples.   This is the first time that manufacturing was doing all the testing and programming.  All four boards failed to program.   This design is a modification of a previous design, which they have built and programmed a lot of.  So manufacturing is familiar with programming this exact PSoC using the same MIniProg3 and JTAG cable setup.

The two PSoCs on the board are connected in a JTAG daisy-chain.   There are zero ohm series resistors that allow the PSoC to be isolated from the chain.   By lifting these resistors and using SWD mode,  I found that both PSoCs on all four boards cannot be programmed.   I verified my cable, MiniProg3 and setup by testing the same way on a good board and it worked fine both in JTAG and SWD mode.  In JTAG mode,  I scoped the TDO pin of both PSOCs during a JTAG scan.  It is floating low.   It does not appear to be driven,  if I weakly bias the pin, it floats to whatever voltage I am biasing it at.  

So, my dilemma is I don't want to call it "WOL" locked chips and tell the assembler to flush all inventory if it is not that.  I also don't want to overlook a test procedure problem that may have caused them to damage the parts earlier in the test process.   Because, that would mean that the problem would appear again on a much larger production build.  

[BiBi_1928986]

Hello stmi.

In the 5LP Programming Spec:

https://www.cypress.com/file/119651/download

perform a word search for 'write once'.

Chapter 3.8, it describes how to program the WOL.  And, at the beginning of this programming sequence, it describes how to READ WOL to check it before trying to program it.

Chapter 5.8 shows SWD commands and WOL address.  Follow the code and you'll see how to read WOL with SWD commands.

However, it doesn't describe how to do this using MiniProg3.  I don't have a MiniProg3 so I can't help you.  I believe there are commands (scripting) called CLI(?) that can be used with MiniProg3, but I have no experience with it.

If doing more WOL word searching in Cypress documentation, you'll find Cypress uses: WOL, WO Latch, Write Once Latch, write once latch, Write Once latch and sometimes just WO.

I hope this gives you some further info.

[StMi_4761721]

Thank you for the links to the Programming Manual.   I took a look at the CLI interface.   I did get it to open in command line and find the Mini-Prog3.   However, that is about as far as I got tonight.   I sure it is a very powerful tool.  But since it gives you control of so much, it requires a lot of setup steps.   I will keep reading the manuals and see if I can figure out the proper flow. 

[StMi_4761721]

With the topic of reading the WOL Status,   my guess is that I have to do this through DAP operations.   Reading thorough the CLI manual, my initial guess at the commands are below.    Due to COVID,  I do the bulk of my work remotely and then go into the office in the evening to do any hands on lab work.   So,  I cannot try this until  later tonight.    Do the commands below look reasonable?  

( For others, I found that I have to change the command prompt to the folder containing the ppcli.exe or it won't work.  Also, the period after the MiniProg3 string is important.  That tells it to load a helper.hex file.   Don't skip the period!    Use GetPort to list the ports so that you can get the ID string of your device.)

OpenPort MiniProg3/1229DD001023 .

SetAcquireMode "Reset"

SetProtocol 8

SetProtocolClock 152

SetProtocolConnector 1

SetPowerVoltage 5.0

DAP_Acquire

PSoC3_DebugPortConfig 4

DAP_ReadIO 0x400046EA

[Rakshith]

Hi StMi_4761721​,

Can you please let us know if this worked?

I found that I have to change the command prompt to the folder containing the ppcli.exe or it won't work

A small correction to this:

The period, in the end, is used to specify the directory of PPCLI. So when you open the command prompt in the PPCLI directory (by default C:\Program Files (x86)\Cypress\Programmer), the period holds good as it indicates the current directory. If the present working directory of command prompt is different, then the PPCLI directory needs to be specified. Ensure that the slash is corrected i.e., forward slash is used.

This is the script I used:

GetPorts

OpenPort MiniProg3/1519DD000A3F "C:/Program Files (x86)/Cypress/Programmer"

quit

This was the result:

Hope this helps,

Thanks and Regards,

Rakshith M B

[StMi_4761721 · Accepted solution]

Here is an update.   The PSoCs were NOT WOL  locked.    The root problem was a defective in a supervisor circuit that was connected to the XRES line.    It is not my design, so I was unaware of this additional connection.   The XRES signal went four places,  the JTAG connector, both PSoCs and this supervisor.  

Since the PSoCs are not locked,  I don't have a pressing need to verify registers with CLI.   I want to attempt it for my own knowledge.  However, getting time to do it is another issue.  Right the majority of my work is done remotely.  I only have a couple of hours of hands-on lab time due to COVID restrictions.    When I get a chance,  I will try the CLI .

[Len_CONSULTRON]

StMi,

I'm very glad you found the issue.   To many of us monitoring this discussion, it didn't sound like it the WOL was set in your case based on your description.  Sadly, the document makes no reference to being able to directly read the WOL setting from the SWD or JTAG interface. (Probably setting the WOL causes the HW interface to programming and debugging to be lost.  This is probably to prevent side-channel attacks by hackers.)

Len