Hello,
I’m currently trying to use the ADC offset property to capture traces beyond the initial 24400 sampling point limit of the CW-Lite. I’ve previously tried the segmented buffer fifo fill method, but this won’t work because of the 24.4k limitation and the distance between the operations I want to get.
My points of interest each lie ˜6500±500 sampling points apart; I’m trying to get the tweak updates of XTS-AES Algorithm (i.e T_j → T_j+1) transitions. It is my understanding from reading the Scope API documentation regarding the offset property, that it starts capture after these many sampling points.
My idea is that for the first sample, I have no offset at all, then for the second one an offset of 6500, next one 13000 (This is based on the idea, that the offset is applied to the very start, and not to the previous measurement…), etc. then just concatenate these measurements and plot them.
I pass the offset as arguments to the two capture functions and then have an independent code block below that goes to the amount of segments I want and updates the offset by multiplying the loop variable by the distance each iteration.
5000 is a lot so to replicate the proble
The first segment (5000x1/128) gets calculated without issue, but then I get:
I don’t exactly understand what is going on here - I’m not filling the ADC buffer over the 24.4k limit, instead using that each individual time to compute what I want and then throwing it together or did I missunderstand the logic behind the offset property?
I’ve gone through this thread: Problem using offset to capture long traces but it hasn’t particularly helped me yet
EDIT: I have patched out a bug I had where I was applying the offset for each individual trace used to calculate a final noise minimized one but with a higher number of total_updates (i.e total times I want to get ‘individual’ traces) I still get the same error:
I’ve rewritten the firmware to be able to manually force tweak updates through simple serial, and noticed that my program would crash it I measured beyond the tweak updates. I will finish exploring this avenue and report back, interesting enough - with clkxgen=4 I didn’t get openADC. I’ll finish exploring this avenue before returning here and reporting on the original firmware and using longer data (i.e tweak updates depend on the encrypted sectorSize / plaintext).
You have the correct understanding of scope.adc.offset and the code you show here looks alright (assuming that the target is responding as expected to each of the ‘s’ commands).
But I don’t understand where the 5000 is coming from (and there is no tnrange in the Python code that you show) so you must be running something different from what you show here for those captures?
If you run your captures with the offset always the same, does it work then?
I am terribly sorry for the late update; I’ve been doing some experiments on my own and made some progress but am yet to solve my issues.
The 5000 is the number of traces I take and then normalize and average out ot minimize sound, since 5000 is a rather high amount, it takes quite a while and I decided to drop the number to 50 - 500 for testing purposes.
I’ve programmed into the firmware as well as the python side an iteration / counter that basically allows me to specify which tweak update I want from the thing, if(ctr == iteration) { trigger_high(); }
basically. Then just pass that via SS2 in the python side of things as an argument. With 24.4k sampling points I get 4 tweak updates (each spaced apart about 5-6k sampling points) with the first one always being the requested iteration one.
However I’m afraid either something is seriously off with my firmware or my measurements are off, because I’m unable to see a difference in the traces between (16 times 0x00, and 16 times 0xff, where bit inversion happens a lot in comparison to none at all). The open source XTS-AES implenentation I had brought a lot of tests and the function I modified repassed all the tests which leads me to believe that everything (should be) in working order.
I decided to return to this problem I had with offset, I think the ADC is breaking because it’s being requested to deal too quickly with the data, I’ve had to hammer in a sleep before capturing each trace, as well as before each individual segment is captured, these two sleeps have solved the problem I had in this thread.
Once again, apologies for the late reply, I have been trying to solve my issues by way of my little counter detour, I’ll update this thread with any more information I find.
It’s hard to diagnose the problem without seeing your full capture code; could you paste all of the capture code as text (not a screenshot)? Use the “</>” icon to get the code formatting.
This is not normal; what does “ADC is breaking” mean? What’s the error message?
My best guess is that this:
isn’t working as intended. If you have a logic analyzer, probe the UART and trigger lines to see whether the trigger is happening when you expect it to. A screenshot of that could be helpful for quickly pinpointing the problem.
