Hello everybody,
I’m currently trying to capture multiple traces but I always get the same message if I go above 4 or set the ADC samples to something bigger than 6k.
(ChipWhisperer Scope ERROR|File OpenADC.py:787) Received fewer points than expected
I have a C/C++ XTS-AES Implementation I’m flashing onto a STM32F4 using the built in program function, I’ve placed my triggers around the code responsible for the tweak updating part of the encryption algorithm. Since I’d like to highlight some power differences, I’ve decided to isolate that part of the algorithm and run it it inside a 10 time for loop in the C/C++ part.
New users can only post one picture, so I will have to condense it all into one for you to see.
Now I’m doing the following:
As you can see, if I set it to above 4, I get the previously mentioned error. I’m using the default_setup of the Scope API. This probably has something to do with the way the ADC is setup, but I cannot figure it out. Maybe it is not updating quick enough and I need to sleep or something?
The problem is that you are calling scope.arm() only once. You need to arm the scope before every capture_trace().
For reference, look at how our stock capture_trace() method does it: chipwhisperer/software/chipwhisperer/__init__.py at develop · newaetech/chipwhisperer · GitHub
1 Like
Hey thanks for the quick answer and sorry for getting back to you late, I did try it out and it worked fine. Small note the ADC still ‘crashes’ sometimes but rerunning my tests corrects it then. I had to eliminate scope.arm() and just place it directly at the start of my capture_trace().
I was always under the impression, that the scope need only be armed once lol. I’ve looked into the setup_generic code and I’d like to know when and how to exactly use reset_target(scope). Sometimes I ran quite a few samples and eventually got jibberish, but then using the reset function got it again, when should I reset the scope in any case?
reset_target(scope) resets the target; it’s not normally required, except for glitching campaigns (to reset the target to a known good state). Also I think some targets may require it after programming.
If you need it while capturing traces, then something isn’t quite right, either in your target firmware, or in your Python trace capture code.
Hm alright, yeah before I implemented the fix you suggested, if I took for example N = 4 because that was the limit, say I ran the for loop like 10 times, it would seize and bug up, but now it works flawlessly. Would you suggest just adding it at the start of the python code right after the imports just to always reset it before any measurements are made or is that plain unnecessary?
It shouldn’t be necessary.
