How to solve this warning?


#1

Hey,

I get the following warning when I try to connect chipwhisperer. Could anybody tell me what caused the issue and how to solve it?

Could not execute method run in script class UserScript: ‘IOError:[Errno FPGA Done pin failed to go high, bad bitstream?] <zipfile.ZipExtFile object at 0xab21932c>’

Traceback (most recent call last):
File “/home/cwuser/chipwhisperer/software/chipwhisperer/common/api/CWCoreAPI.py”, line 394, in runScriptClass
return eval(‘m.%s()’ % funcName)
File “”, line 1, in
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scripts/Inforce.py”, line 47, in run
self.api.connect()
File “/home/cwuser/chipwhisperer/software/chipwhisperer/common/api/CWCoreAPI.py”, line 277, in connect
return self.connectScope() and self.connectTarget()
File “/home/cwuser/chipwhisperer/software/chipwhisperer/common/api/CWCoreAPI.py”, line 239, in connectScope
self.getScope().con()
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scopes/base.py”, line 60, in con
if self._con():
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scopes/OpenADC.py”, line 99, in _con
self.scopetype.con()
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scopes/openadc_interface/naeusbchip.py”, line 108, in con
self.getFWConfig().loadRequired()
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scopes/cwhardware/ChipWhispererFWLoader.py”, line 240, in loadRequired
self.loader.loadRequired(self.loadFPGA, forceFirmware)
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scopes/cwhardware/ChipWhispererFWLoader.py”, line 186, in loadRequired
callback()
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scopes/cwhardware/ChipWhispererFWLoader.py”, line 267, in loadFPGA
self.loader.loadFPGA()
File “/home/cwuser/chipwhisperer/software/chipwhisperer/capture/scopes/cwhardware/ChipWhispererFWLoader.py”, line 193, in loadFPGA
self.driver.FPGAProgram(self.fpga_bitstream())
File “/home/cwuser/chipwhisperer/software/chipwhisperer/hardware/naeusb/fpga.py”, line 84, in FPGAProgram
raise IOError(“FPGA Done pin failed to go high, bad bitstream?”, bitstream)
Warning: Could not execute method run in script class UserScript: ‘IOError:[Errno FPGA Done pin failed to go high, bad bitstream?] <zipfile.ZipExtFile object at 0xab21932c>’


#2

Hi Daniel,
Could you please send me the chip whisperer lite serial number and the firmware version you are using?
This can be found in the “debug logging” tab in the bottom subwindow in the capture software, when the connect to scope button is pressed.
Kind Regards,
Franz


#3

Hi Franz,

INFO - Found ChipWhisperer-Lite, Serial Number = 4420312046304a383030312036313032
INFO - SAM3U Firmware version = 0.11 b0
INFO - Detected ChipWhisperer with USB ID ace2 - switching firmware loader
ERROR - Traceback (most recent call last):


#4

Good for you buddy, if I take a tour my problem will be solved?


#5

Hello,

Are you running inside a VM? I’ve seen this issue before with VM devices sometimes and never fully solved it I think.

Q#1: Are you using the latest SW?

The one thing to try is force setting a specific FPGA bitstream. This can be done under “Tools --> CW Firmware Preferences”.

Q#2: What is that currently set at? It should be" Builtin". You can try switching to “External (.zip)” which should find itself pointed at “chipwhisperer\hardware\capture\chipwhisperer-lite\cwlite_firmware.zip”.

Regards,

-Colin


#6

Hey,

Yes I was running inside a VM, I tried it from a chipwhisperer capture (version 3.5) installed on windows and it gave me the same warning.
It is set to builtin, but even when I try to set it manually to external the program fgpa button is inactive.


#7

Hi Daniel,

Sorry on slow response - we’ve had that issue before and I’ve been trying to find the previous fixes, as I didn’t well document it (some of them were committed to GIT as well so thought maybe it would already be sorted out).

Setting to manual is a little odd. You need to first set to manual/zip-file, then disconnect/reconnect. It should detect the FPGA is not programmed and send the new bitstream to the device.

Did it ever work or is this a new device? The hardware is pretty robust so unlikely to be damaged, but anythings possible so want to figure out exactly.

-Colin


#8

Hi Colin,

I tried the suggested solution but with no luck…
Yes it was working, and at some point it just started giving me this error.
Also I had to find a pc that is not behind a proxy… The installations of chipwhisperer doesn’t ‘always’ like to run on every pc (strange), or in the list where you should choose the scope module only “none” is available… So this is why I preferred to use the VM (working from windows).

Any idea of what might be wrong and how to solve it?

Daniel


#9

Hi,

I finally had time to take a closer look on it, the 3.3V and the ground was shorted. Under the thermal camera the atmel chip emitted some heat, but there were other differences between a working unit and this, so I opted to take off the ADC, VGA, FPGA and micro. The ADC and VGA seems to be fine, as they don’t have short between VDD and GND, and from the PCB the short also disappeared which leaves the micro or the FPGA.
Any idea what could cause the issue under normal use?
I have some suggestions, in the next iteration of the PCB try to ground everything properly, including USB and the stands. I am working on ESD protected surfaces and if some charge gets grounded, it has a potential gradient, and with the longer distance it becomes greater. I can imagine that as the stands are not connected to the ground (but cooper on the PCB is close to it on multiple layers as I saw it under X-ray) 5-8KV or more (with tiny amount of current) was present and it found a way through the FR4. Or this or the board self destructs. PCB design is not black magic. Also between the traces, flood everything with cooper (except in the analog part). For start google high frequency pcb design.


#10

Hello,

Hmm - this short would be odd in regular use! The FPGA might be more likely as it is “device facing” (i.e., if you put 5V in by accident to target device). Note there are separate power nets for the SAM3U & FPGA, so you should be able to determine which 3.3V rail. If it’s a solid short I think it’s possible it is something physical on the pins of the chip? Actually since the SAM3U is working it should most definitely not be that. If it was something (metal flake, solder ball, etc) that might have also cleared during the removal process.

The SAM3U gets hot normally as it has an internal LDO regulator. So it will be warm in regular use.

We didn’t ground the legs on purpose, as it is too easy to introduce a ground loop if you mount the ChipWhisperer-Lite on a metal platform. The closest traces are all GND pours so I’d guess if ESD was to blame it would be from another avenue (likely target connections as they have less ESD protection, mostly relying on FPGA ESD diodes).

But if you are seeing 0-ohm short I’d see which VCC net it’s on which might help you narrow down specifically.

-Colin


#11

Hi,

Under the thermal camera on a normal functioning unit, without being connected in the gui the mC, the FPGA, ADC, and VGA was warm.
In the faulty unit the mC and VGA was warm and U5 (LTC3419EMS), more specifically the 3,3V side with the coil (L2) included. But not the ADC nor the FPGA. Moreover there was no heat coming from between the pins of the FPGA from a short of any kind. I inspected the removed ADC and VGA chips with continuity tester and they didn’t have internal shorts.
I don’t think the FPGA could get damaged from “facing the device” as good GPIO handling practice recommends every used pin is connected through a 50 ohm series resistor (you can get them in resistor net package in surface mount form, although they might introduce some crosstalk depending on the edge transition rate) and every unconnected pin is directly grounded and internally set to input. Output pins left floating, and of course differential signal pairs has to be impedance matched (the pcb trace as well), in case the signal can finish it’s state transition on the source side while to the sink end of the trace the signal did’t arrive yet (travel speed, length…), as it will introduce reflections, ringing, jitter, etc
Ground loop is only a problem if you route the ground sequentially instead of a star pattern as the backward current, which returns to the source from the sink, will introduce a potential difference along the way (resistance of ground trace), which might affect the grounding of other devices/IC/etc. If the CW would be connected to a metal plate, that wouldn’t be a problem. If that metal plate would be separately grounded, then the ground loop would only affect the part of the star pattern grounding which is connected to the mounting holes, and would leave the rest of the device unaffected. All of this can be solved by the use of ground planes, but if manufacturing costs doesn’t allow it, then gridding the ground (on one plane ground traces go North-South direction and on another plane they go West-East. Every point where the grids overlap is connected by vias (those would be also ground loops in some sense, but they still aren’t) ) can be almost as effective.

The issue - you mentioned that previously seen it, FPGA pin failed to go high - was it solved? Did it turned out what was causing the problem?


#12

Hello,

The ground loop issue I mention is more related to overall system ground loops. i.e., USB connector is connected to computer ground via USB cable. If you have device on a conductive surface it may be grounded via another device’s chassis which may not be plugged into same outlet. This can give you a pretty bad ground loop issues, and basically at risk of damaging a computer. So on account of that we didn’t want to ground the standoffs.

Did it turned out what was causing the problem?

The other times we’ve seen this issue were resolved with changing from VMWare into using installed software, so assumed it was problem with USB stack delays.

between the pins of the FPGA from a short of any kind

The switching reg would be going into shutdown mode automatically on account of the short, so you wouldn’t see any heat that way.