I’d like to create a target that is not a MCU or FPGA, but a peripheral controlled through SPI - a security chip.
I’ve looked at Husky docs and Husky “Care & Feeding Instructions” part “Adding a new target”.
The target board used would be either the CW308 UFO style or CW312 style. Is there much of a difference when I could choose which one (and use either UFO board of CW313)? I have blank boards for both or maybe had it manufactured as PCB.
Generally I have rough idea what needs to be done, but hazy on few parts.
I have 2 questions before moving forward:
Connection
As SPI peripheral, it doesn’t have a clock like MCU does (just SPI + VCC + GND). I count SCK pin as part of SPI interface. So that means leave clock unconnected - but would it somehow affect some synchronization in Husky hardware or software?
That also likely means using TIO1-TIO4 for connecting SPI to CW.
Is there significant advantage to make such target board as PCB from machine compared to hand-soldering it in terms of electrical characteristics?
Triggers
I see the 20-pin header on Husky (and Lite) has SPI, which IIRC was used to program some MCUs like AVR. But my understanding is that it probably can’t be used for sending commands to the target from CW jupyter/python and at the same time using triggers.
This means I’d need to use extra board like a MCU or GreatFET to communicate with the SPI target and trigger probably with edge count on SCK to know when the command was sent.
Then, can I arm both edge count and SAD trigger? I.e. wait until controller (GreatFET) sends command to target (edge count trigger on SCK), from that moment on make SAD (or multi-SAD) trigger active?
The CW308 has some additional features for voltage supply and IO protection, but if you don’t need the additional voltages then either one will work.
Yeah, you won’t have synchronization between the ADC clock and the target clock in this case. I assume there’s no crystal for the chip?
It’s hard to say without knowing the exact chip, but so long as the chip functions, it should be okay. You’ll probably get less noise in your traces with a nice PCB done up, but that may not end up mattering depending on what the chip is doing. Even if it does matter, it also may just be the difference between an hour and a few hours of capturing traces or so, which you may or may not care about.
I’d have to check the microcontroller code, but I’m pretty sure you’re right - I think a lot of the bootloader protocol is on the microcontroller and the python code ends up using that instead of raw SPI. This is definitely something that could be added though without too much effort.
No, you need to choose one or the other. The SAD trigger is pretty specific, so IMO it’s not likely that it’ll match anything besides the specific area you’re looking for.
Yes, there is no crystal for the chip. So I may just add some jumpers to connect HS1/HS2 to SCK, but I think it won’t be very useful. Chip datasheet should be public soon. It should include some anti-glitch features which if implemented as is written, should make it an interesting and hard target.