python script error when reading back SRAM

[doegox]

Trying the script, loading SRAM to the board worked fine, pressing Enter (without even EMFI), getting this error

ChipSHOUTER-ballisticgel/ballisticgel$ python ballisticgel.py 
 CW521 Ballistic Gel Example Script 
  by NewAE Technology Inc
 This script will continue until you exit with Ctrl-C
Settings: 
  Using slow (raw) mode  : True
  Showing plot of results: False
  Results filename       : None
Starting main loop now: 

LOOP START: Writing data to SRAM...
 Hit enter when glitch inserted
 Reading SRAM data...
Traceback (most recent call last):
  File "ballisticgel.py", line 329, in <module>
    results = cw521.raw_test_compare()
  File "ballisticgel.py", line 243, in raw_test_compare
    din = cw521.read_pattern()
  File "ballisticgel.py", line 102, in read_pattern
    din = self.usb.cmdReadMem(start_addr, len_to_read)
  File "/home/qb/00hardware_guilde/haqerspace/tools/chipshouter/ChipSHOUTER-ballisticgel/ballisticgel/naeusb.py", line 228, in cmdReadMem
    data = self.usbdev().read(self.rep, dlen, timeout=self._timeout)
  File "/home/phil/.local/lib/python2.7/site-packages/usb/core.py", line 988, in read
    self.__get_timeout(timeout))
  File "/home/phil/.local/lib/python2.7/site-packages/usb/backend/libusb0.py", line 542, in bulk_read
    timeout)
  File "/home/phil/.local/lib/python2.7/site-packages/usb/backend/libusb0.py", line 627, in __read
    timeout
  File "/home/phil/.local/lib/python2.7/site-packages/usb/backend/libusb0.py", line 431, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] Connection timed out

[colinoflynn]

Odd! We run that exact script as part of the test so the board HW should be fine... but I suspect it's some unknown compatibility problem.

What's your host OS?

[doegox]

Linux, Debian 10.0 kernel 4.20
I poked around, if I set a large timeout on naeusb.py", line 228, the script doesn't crash but I get absurd results:

 Reading SRAM data...
Byte errors: 4178047 (of 4194304). Bit errors: 8387684 set (0 --> 1), 8387695 reset (1 --> 0)

Note that on the board, USB RX is steadily red for a while while SRAM gets loaded, but USB TX flashes only very briefly when SRAM gets read back.
So it seems that it's really the board that doesn't send much data back.

[colinoflynn]

IIRC The USB TX led direction is a bit of a "bug"... the TX led gets set internally when the read-back starts, but the rest is done via DMA and it's no longer calling the USB routines for every transaction.

Also you can try switching between the "fast" and "complete" mode to see if it changes things. I'm going to try and recreate here on a Linux machine, our test machine was Windows I admit so I could have missed something there.

[doegox]

about "large timeout on naeusb.py", line 228", here are some effects depending on the injected timeout:

• 0..4000 -> error
• 5000 -> absurd results, as shown above
• 6000 -> results that make sense (0 bitflip, more bitflip when EMFI)

[doegox]

use_raw_method = False => works fine without hacking the timeout (including when slower after EMFI).