Hi All,
I’m a new howner on this tool and I’m having the same problem related to the programming of XMEGA board supplied with my ChipWhispererLite.
I’ve installed manually on 2 different windows 10 PC and got the same behaviour.
Any suggestion?
Is there a tool to check in the target board is working and can be programmed?
Any help is wellcome.
Thank you
Hi all again,
I’m sorry but I’ve not realized this was a 3 years old post.
I’m worknig with ChipWhisperer 5.0 on python 3.7 so probably a different environment.
Can someone tell me how to move my post to an appropriate position?
Regards
Hi, what exactly is the error message that you get?
Also make sure you’re using a known good USB cable.
Jean-Pierre
Hi Jean-Pierre,
Yes I’ve tried with some other USB cable that works fine for other targets (STLINKV2, Diligent Analog Discovery 2 etc.) with same results.
I’ve run one simple intor in Notebook to have a clean situation: in the following the results:
Jupyter Notebook: PA_Intro_1-Firmware_Build_Setup
I’ve selected the platform modifing the first variable assignements:
SCOPETYPE = ‘OPENADC’
PLATFORM = ‘CWLITEXMEGA’ #‘CWLITEARM’
Everithing works fine until the target program where I’ve got this error:
OSError Traceback (most recent call last)
in
----> 1 cw.program_target(scope, prog, fw_path)
c:\chipwhisperer\chipwhisperer\software\chipwhisperer_init_.py in program_target(scope, prog_type, fw_path, **kwargs)
51 prog._logging = None
52 prog.open()
—> 53 prog.find()
54 prog.erase()
55 prog.program(fw_path, memtype=“flash”, verify=True)
c:\chipwhisperer\chipwhisperer\software\chipwhisperer\capture\api\programmers.py in func_wrapper(self, *args, **kwargs)
68 self.scope.io.nrst = ‘high_z’
69 try:
—> 70 val = func(self, *args, **kwargs)
71 finally:
72 logging.debug(‘Restoring pdic, pdid, and nrst pin configuration’)
c:\chipwhisperer\chipwhisperer\software\chipwhisperer\capture\api\programmers.py in find(self, xmega)
223 def find(self, xmega=None):
224 xmega = self.xmegaprog()
–> 225 sig, chip = xmega.find()
226
227 # Print signature of unknown device
c:\chipwhisperer\chipwhisperer\software\chipwhisperer\hardware\naeusb\programmer_xmega.py in find(self)
173 def find(self):
174 self.setParamTimeout(100)
–> 175 self.enablePDI(True)
176
177 # Read signature bytes
c:\chipwhisperer\chipwhisperer\software\chipwhisperer\hardware\naeusb\programmer_xmega.py in enablePDI(self, status)
307 if status:
308 # self._xmegaDoWrite(self.XPROG_CMD_LEAVE_PROGMODE)
–> 309 self._xmegaDoWrite(self.XPROG_CMD_ENTER_PROGMODE)
310 self._pdienabled = True
311 else:
c:\chipwhisperer\chipwhisperer\software\chipwhisperer\hardware\naeusb\programmer_xmega.py in _xmegaDoWrite(self, cmd, data, checkStatus)
502 status = self._xmegaDoRead(cmd=0x0020, dlen=3)
503 if status[1] != 0x00:
–> 504 raise IOError(“XMEGA Command %x failed: err=%x, timeout=%d” % (status[0], status[1], status[2]))
505
506 def _xmegaDoRead(self, cmd, dlen=1):
OSError: XMEGA Command 20 failed: err=1, timeout=1
Thank you again
Maurizio
Hmm… are you using the CW308 UFO target, or just the CW1173 basic board?
I haven’t come across this problem before, and the only way I can reproduce it is if I try to program an ARM target with the XMEGA programmer. That gives me the exact same error you get. Are you sure you have an XMEGA target?
Jean-Pierre
I’m using a ChipWhisperer Lite 2-Part Version which inclute a 8-bit ATXMEGA128D4 target; I think it should be equivalent to an cw1173 basic board.
I’ve attached the photo of the processor (hope you can see it)
I’ve connected the target via the flat cable and both the coax cables, then I’ve tried again with only measure coax connectd (removing glitch) with the same results.
I’ve selected the platform CWLITEXMEGA, is it correct?
On the ChipWhisperer board I have a blue led blinking at about 1 Hz and a green led blinking at higher speed (maybe the double) while on the targer board there are two leds (green and red) fixed on.
Maurizio
Having a look at the windows driver i saw that even if the driver seems to work correctly something went wrong:
"La migrazione del dispositivo USB\VID_2B3E&PID_ACE2\50203120324136503030342033313032 non è stata eseguita a causa di una corrispondenza parziale o ambigua.
ID ultima istanza dispositivo: USB\VID_059F&PID_1010\ST3500830A____________9QG7K1Y2
GUID classe: {36fc9e60-c465-11cf-8056-444553540000}
Percorso: PCIROOT(0)#PCI(1A07)#USBROOT(0)#USB(5)
Classificazione migrazione: 0xF000FFFFFFFF0123
Presente: false
Stato: 0xC0000719
"
Sorry it is in italian due to the windows installation language. basically it says that “the USB device migration was not was not performed due to a partial or ambiguous correspondence …”
Anyway cw.scope seems to work.
Do you think it could be tha cause?
Do you know if there is a way to fix it?
Maurizio
Main board LEDs are behaving as expected, while on the target board normally the LEDs should be off however they are driven directly by the target firmware.
Did you install the CW Windows drivers successfully? What do you see in Device Manager?
This is the display driver window:
The same of yours except fpr the language settings…
About the events I listed above: it was the first event (before drive installation). Last two events show that everithing went well…
Is there am application to test it whitout use python? (Maybe some exe)
As far as I read it seems that the ChipWhisperer firmware should be upgraded automatically, is there something I can check to see if I’m using the latest revisions?
No, I don’t think we have any other application to test it. If you haven’t tried it yet, do you mind trying the VM install? It would eliminate a few variables.
Jean-Pierre
Hi Jean-Pierre,
Finally I didi it and the results are the same.
I had some problem in having jupyter workning. I had to install the gnome environment on the virtual machine to be able to run Firefox and work with it.
I’m not an expert of VirtualBox and linux so I can’t have window Chome opening the localhost:8888 to see the Jupyter server runnin on debian in VirtualBox…
Don’t know how to go on…
Is there some signal I can check with an external scope? (maybe on the target connector)
Ah, I think you misunderstood how the VM is meant to be used.There is no need to install anything in the VM; you browse to localhost:8888 on your host machine, not in the VM.
So, after following all the VM installation instructions, all you do with the VM is start it. Don’t even log in. Then in Windows go to localhost:8888.
Jean-Pierre
Yes, I’ve followed the installing instructions but:
).Later on i will try to disconnect the DeskTop PC from LAN network to see if it will works an will let you know.
Trying Python in debug I saw that the problem seems to be in the answer from the target.
If you are interested in these details I can send you some screenshot later today.
Thank you and best regards.
PS: I saw in some old posts (on github) someone had a similar problem and the suggestion was to verify the voltage level on some pins because of possible voltage missmatch. Do you think it could be also my case or it was an old issue already fixed?
Fisrt test: I succeed in having the original VM working in VirtualBox as expected and with the USB enabled.
So tested as suggested with the same result:
OSError Traceback (most recent call last)
in
----> 1 cw.program_target(scope, prog, fw_path)
~/work/projects/chipwhisperer/software/chipwhisperer/init.py in program_target(scope, prog_type, fw_path, **kwargs)
51 prog._logging = None
52 prog.open()
—> 53 prog.find()
54 prog.erase()
55 prog.program(fw_path, memtype=“flash”, verify=True)
~/work/projects/chipwhisperer/software/chipwhisperer/capture/api/programmers.py in func_wrapper(self, *args, **kwargs)
68 self.scope.io.nrst = ‘high_z’
69 try:
—> 70 val = func(self, *args, **kwargs)
71 finally:
72 logging.debug(‘Restoring pdic, pdid, and nrst pin configuration’)
~/work/projects/chipwhisperer/software/chipwhisperer/capture/api/programmers.py in find(self, xmega)
223 def find(self, xmega=None):
224 xmega = self.xmegaprog()
–> 225 sig, chip = xmega.find()
226
227 # Print signature of unknown device
~/work/projects/chipwhisperer/software/chipwhisperer/hardware/naeusb/programmer_xmega.py in find(self)
173 def find(self):
174 self.setParamTimeout(100)
–> 175 self.enablePDI(True)
176
177 # Read signature bytes
~/work/projects/chipwhisperer/software/chipwhisperer/hardware/naeusb/programmer_xmega.py in enablePDI(self, status)
307 if status:
308 # self._xmegaDoWrite(self.XPROG_CMD_LEAVE_PROGMODE)
–> 309 self._xmegaDoWrite(self.XPROG_CMD_ENTER_PROGMODE)
310 self._pdienabled = True
311 else:
~/work/projects/chipwhisperer/software/chipwhisperer/hardware/naeusb/programmer_xmega.py in _xmegaDoWrite(self, cmd, data, checkStatus)
502 status = self._xmegaDoRead(cmd=0x0020, dlen=3)
503 if status[1] != 0x00:
–> 504 raise IOError(“XMEGA Command %x failed: err=%x, timeout=%d” % (status[0], status[1], status[2]))
505
506 def _xmegaDoRead(self, cmd, dlen=1):
OSError: XMEGA Command 20 failed: err=1, timeout=1
Hi Jean-Pierre
Finaly I’ve been able to program the target and run completely the PA_Intro_1-Firmware_Build_Setup.
To do it I had to disconnect both the MEASURE and GLITCH coax cable (until last experiment I had the MEASURE coax cable connected).
Is it correct or there is something wrong with the Hardware?
That’s great, happy to hear it.
You may have run into a known issue that I’d forgotten about, where the MOSFET used for glitching becomes stuck (see here, here).
Can you check the voltage between the middle pad and either one of the side pads of the glitch port? (should be 3V).
I’m also curious if you’re able to progress further on the tutorials?
Jean-Pierre
Dear Jean-Pierre,
I’ve checked the voltage on glitch port : it is about 60mV so it seems to be good, isn’t it?
In the meantime I’ve discovered that one of the two coax cable is shorted!!!.
Tested again with the good cable connecetd to MEASURE connector and works well.
Is there a way to obtain a working cable (we’ve bought the board via Mouser) eventyually returning the wrong one?
About the tutorials: I’m going on slowly, looking forward for next week end to have some time to go on.
Thank you again
Maurizio
Good catch on the bad cable – that’s the root cause of your problems right there.
Can you message me your email address so I can follow up regarding your bad cable?
Jean-Pierre
Hi Jean-Pierre,
I’m not sure I’ve sent you a message with my email. Can you confirm it?
If not can you give me some info on how to share it with you?
Thanks
Hi there,
Just bumping this because I’m running into this problem as well on the XMEGA boards.
I don’t think it’s completely an isolated issue with stuck MOSFETs since I’m running into the same problem. It might be a problem with the API?
Additionally, I’ve tried the simpleserial AES tutorial using an STM32F3 board I have, which works fine, further suggesting it may be a problem with the software.
Hi,
When you switch from the STM32 target to the XMEGA target, are you changing the PLATFORM variable accordingly in the notebook? If so, what exactly is the error message that you get?
Jean-Pierre
