Issues while programming CW305 Boards

Sami_BA · September 22, 2021, 1:38pm

Greetings,

I have 2 CW305 boards, each with a different issue.

For the 1st board, I was using it along with CWLite for the CW305 AES attack jupyterlab installed on ubuntu 18.04. It was working fine (programming was just OK) until the FPGA failed to be programmed using the bitstream provided by the jupyter lab. The following warning is displayed:

WARNING:ChipWhisperer Target:FPGA Done pin failed to go high, check bitstream is for target device.

I tried to unplug the boards and restart jupyter but that didn’t help. I also tried upgrading the firmware using the CW upgrade firmware script provided in Jupyter:

import chipwhisperer as cw
target = cw.target(None, cw.targets.CW305)
prog = cw.SAMFWLoader(target)
prog.auto_program()

I got the following output but the problem still persists:

WARNING:ChipWhisperer Target:No FPGA Bitstream file specified.
Entering bootloader mode...
            Please wait until the ChipWhisperer shows up as a serial port. Once it has, call
            the program(COMPORT, FWPATH) to program the ChipWhisperer

            Default firmware can be found at chipwhisperer/hardware/capture/chipwhisperer-lite/sam3u_fw/SAM3U_VendorExample/Debug/SAM3U_CW1173.bin
Detected com port COM4
Loading cw305 firmware...
Opened!
Connecting...
b'\n\r'
Connected!
Erasing...
Erased!
Programming file SAM3U_CW305.bin...
Programmed!
Verifying...
Verify OK!
Bootloader disabled. Please power cycle device.

I tried the same on a Windows 10 machine with exactly the same behaviour.

Also there’s a slight buzzing sound on the board which wasn’t present when the board was working.

This same issue happened before, but back then I just tried to program it after a while and it worked, until it happened again recently.

Here’s dmesg output for the 1st board :

[ 4609.128110] usb 1-3: new high-speed USB device number 18 using xhci_hcd

[ 4609.276996] usb 1-3: New USB device found, idVendor=2b3e, idProduct=c305, bcdDevice= 1.00

[ 4609.277001] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 4609.277004] usb 1-3: Product: ChipWhisperer CW305

[ 4609.277007] usb 1-3: Manufacturer: NewAE Technology Inc.

[ 4609.277009] usb 1-3: SerialNumber: 50203120355448513130333231313038

Also, lsusb output for the first board (Device 019):

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 004: ID 04ca:0022 Lite-On Technology Corp.

Bus 001 Device 019: ID 2b3e:c305

Bus 001 Device 002: ID 045e:00cb Microsoft Corp. Basic Optical Mouse v2.0

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

For the second Board, it’s also a CW305, but this didn’t work out of the box when we received it. In this case, when I tried to program the FPGA using the CW305 AES attack jupyterlab, it fails to detect the FPGA and gives the following warning:

Warning: Failed to find USB Device

It’s important to note that I used the same desktop machine as for the other board when it was working, so I dont think it’s an issue with the drivers .

I tried upgrading the firmware too using the CW upgrade firmware script provided in Jupyter, the script fails at execution and produces the same warning :

Warning: Failed to find USB Device

I think the problem is with the microcontroller on board the CW305, because when I changed the mode switches to allow for FPGA configuration from JTAG using a Xilinx Platform cable and Vivado, it just worked.

Here’s the dmesg output for the second board. It clearly differs from a working connection to the USB microcontroller interface from other CW boards (either another CW305 or the CWLite). Note how the detection of manufacturer/product/serial number is failing:

[ 4519.872626] usb 1-3: new high-speed USB device number 17 using xhci_hcd

[ 4520.020865] usb 1-3: New USB device found, idVendor=03eb, idProduct=6124, bcdDevice= 1.10

[ 4520.020869] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0

[ 4520.023056] cdc_acm 1-3:1.0: ttyACM0: USB ACM device

Lastly, lsusb output for the second board (Device 020):

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 004: ID 04ca:0022 Lite-On Technology Corp.

Bus 001 Device 020: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader

Bus 001 Device 002: ID 045e:00cb Microsoft Corp. Basic Optical Mouse v2.0

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

For both problems of these 2 boards I tried to search for a solution on the NewAE forum but I couldn’t find anything that corresponds to the exact problems that I’m having.

Note: worth saying that in none of the cases have we tampered with the board in any way, other than running the default labs. We did modify the provided AES design to adapt it to our needs and resynthesized with Vivado, but that’s just it. In any case all the problems reported here are reproducible with the default labs provided (no change).

coflynn · September 22, 2021, 3:01pm

Hmm - odd behavior! For either board you can force them into bootloader mode by shorting the ‘erase’ pins on the CW305. That is jumper JP5, which is just to the upper right of the SAM3U. This will force the board to a known state if you can’t enter bootloader mode.

From there you can force the firmware load as follows:

import chipwhisperer as cw
programmer = cw.SAMFWLoader(scope=None)
programmer.program('/dev/ttyACM0', hardware_type='cw305') #adjust ttyACM0 to reflect bootloader serial port

This pulls the firmware as a built-in one. You can try an older version of the FW as well with:

import chipwhisperer as cw
programmer = cw.SAMFWLoader(scope=None)
programmer.program('/dev/ttyACM0', fw_path=r'/somewhere/SAM3U_CW305.bin') #adjust ttyACM0 to reflect bootloader serial port

Where you download SAM3U_CW305.bin from chipwhisperer/hardware/victims/cw305_artixtarget/fw/sam3u/CW305_SAM3U_FW/build at 73cdb7ad22bb6a239ef92acfdeed3f7788500cfc · newaetech/chipwhisperer · GitHub. We had a newer build that I think is used by default, but I’ll have to check with @Alex_Dewar as I see some oddness in that directory on the main git branch.

Hmm normally bad! Like the switch-mode power supply isn’t working, see if you touch the power supply chips (U3 or U24) with the back of a pen or pencil it changes. Avoid using your finger as you might touch the feedback network and your slightly conductive fingers will cause that to go out of wack (and could lead to a voltage spike).

If you switch FPGA_POWER (SW5) from ‘AUTO’ to ‘OFF’ does it change?

But if you’re seeing that with FW change I’m wondering if the enable pin isn’t being driven, and it’s just floating the SMPS on/off. There are no buzzers on the board so the inductors are about the only thing that could be the cause… I don’t remember hearing that before even in bootloader mode though so will need to check here.

Thanks,

-Colin

Sami · September 23, 2021, 4:25pm

Greetings,

Thank you very much for your quick reply and your help ,I’ve attempted shorting JP5 jumper as you suggested , the issue I was having with the second board ( the one that doesn’t work out of the box) is now resolved and i was able to program the board using USB .

For the first board ,even after attempting to short JP5 the issue is not resolved .

I’ve attempted to do that and there’s no change .

Yes, when i switch from Auto to OFF the buzzing sound stops.

Again, thank you very much for your help, it is very much appreciated.

coflynn · September 23, 2021, 8:16pm

Hmm so we swapped from one working board to the other!

On the buzzing board - does it change if you switch the computer it’s plugged into? Do you have a scope to check out the power rails?

If it’s too weird we can generate a return shipping label & debug here, drop an email to support@newae.com . This will be about a week total however (shipping to us is typically 2-3 days, a day or two for debug, then 1-2 day return shipping), so if there is some easy remote debugging may be worthwhile.

But using a different computer (and maybe USB-A cable) would be helpful to confirm it’s not a power supply problem. Also toggle the big power switches on/off a few times to make sure it’s also not an issue there. I’m wondering if the input power is dipping causing the buzzing as well (regulators running just at minimum).

Thanks,

-Colin

Sami_BA · September 28, 2021, 10:19am

Thank you for your reply,

I tried using a different computer to power the board but the issue still persists .

I checked the power rails using an oscilloscope, the VCCINT value was stable at 1 v, however there seems to be a problem with VCCIO and VCCAUX, here’s the scope’s measurements for each one:

I’ve also tried that, and the problem is still not solved .

Actually, we are in France, I’m wondering how long the procedure will take in our case.

coflynn · September 28, 2021, 12:40pm

That looks a lot like there is a short or some issue then on the “not-vccint” supply side. Possible there was a short across a pin (as the board is ‘exposed’ something can come across it, or could be a solder ball etc). It seems it is coming online and not a dead short, so harder to say with that. The SMPS does that when it “thinks” there is a shorted output or something else is interrupting it’s power-on (such as problem with a component etc).

The fact VCC-INT is OK makes me think it’s not input power which I suspected originally. While it could be closer to the limit for just one of the supplies, I’d still expect some similarity between them.

It may be a couple extra days for transit - we send a return label which will bring it back via DHL to us so it’s still fairly fast. There is (normally) no customs/tax issues as it’s a repair label, so far we haven’t had problems to EU with that.