Closed nsluhrs closed 4 months ago
Can you show us the output of dmesg
when the device is first connected and after pressing PROGRAM?
[136761.265542] usb 2-1: new full-speed USB device number 31 using xhci_hcd
[136761.415656] usb 2-1: New USB device found, idVendor=1d50, idProduct=615c, bcdDevice= 0.00
[136761.415662] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[136761.415664] usb 2-1: Product: Cynthion Apollo Debugger
[136761.415666] usb 2-1: Manufacturer: Great Scott Gadgets
[136761.415667] usb 2-1: SerialNumber: BGZNYS2MGJJVCIBAEA3C6HAP74
[136761.418767] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
No change in dmesg when pressing program. As far as LEDs on connection A,B,D and 0-5 are lit, D goes out a moment later, and B turns off when program is pressed 3 and 4 are pretty dim so I'm not 100 percent sure it's on
Thank you! LEDs 0-5 are normally in that state (dim but with some brighter than others) when the FPGA is offline (which is indicated by LED B being off).
It looks like the Apollo firmware on your Cynthion's MCU is generally working, but for some reason it is unable to detect the board revision.
Can you please try installing this experimental firmware?: https://github.com/mossmann/apollo/actions/runs/9940795202/artifacts/1702047943
To install, extract firmware.bin
from firmware-binaries.zip
and then do:
fwup-util --device 1d50:615c firmware.bin
Alternatively, if you would like to build the firmware from source, you can use this branch: https://github.com/mossmann/apollo/tree/adc-debug
This experimental firmware hard-codes the board revision to r1.4 and also provides a method to retrieve the ADC value that is normally used to detect the board revision.
Detected a Cynthion device!
Hardware: Cynthion r1.4
Serial number: BGZNYS2MGJJVCIBAEA3C6HAP74
Firmware version: 9fc364c
USB API version: 1.1
Flash UID: 0000000000000000
That seems to have fixed it, let me know if there's any more info you need to try and root cause the problem.
I think that firmware should work fine for you. However, things will likely break again the next time you do a firmware update. I suspect that there is hardware failure preventing automatic hardware revision detection. Can you please show me the output of this test program?
#!/usr/bin/env python3
#
# for use with experimenatal firmware only
from apollo_fpga import ApolloDebugger
import usb
d=ApolloDebugger(force_offline=True)
reading = d.device.ctrl_transfer(usb.ENDPOINT_IN | usb.RECIP_DEVICE | usb.TYPE_VENDOR, 0xff, 0, 0, 2)
print((reading[0] << 8) + reading[1])
I'm running to a very similar issue. I was not able to get the cynthion
tool to connect and the USB device is at /dev/ttyACM0 instead of /dev/ttyUSB. Updating to the experimental firmware does allow the cynthion
tool to connect and appears to have resolved the issue, but I am still seeing the USB device at /dev/ttyACM0.
Detected a Cynthion device! Hardware: Cynthion r1.4 Serial number: 53BTZKKMGJJVCIBAEA3DMHYO74 Firmware version: v1.0.6 USB API version: 1.1 Flash UID: 0000000000000000
dmesg output
[ 6728.285217] usb 1-5.4.1: USB disconnect, device number 22 [ 6728.538070] usb 1-5.4.1: new full-speed USB device number 23 using xhci_hcd [ 6728.670095] usb 1-5.4.1: New USB device found, idVendor=1d50, idProduct=615c, bcdDevice= 1.04 [ 6728.670112] usb 1-5.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 6728.670117] usb 1-5.4.1: Product: Cynthion Apollo Debugger [ 6728.670121] usb 1-5.4.1: Manufacturer: Great Scott Gadgets [ 6728.670124] usb 1-5.4.1: SerialNumber: 53BTZKKMGJJVCIBAEA3DMHYO74 [ 6728.679069] cdc_acm 1-5.4.1:1.0: ttyACM0: USB ACM device
output of the test python script
3235
@ConceitedCode Can you please run cynthion update --mcu-firmware
and then show us the output of cynthion info --force-offline
?
Sure thing!
(env) cam@lotus:~/cynthion$ cynthion update --mcu-firmware
Updating device firmware with 13816 bytes...
Operation complete!
(env) cam@lotus:~/cynthion$ cynthion info --force-offline
Detected a Cynthion device!
Hardware: Cynthion r1.4
Serial number: 53BTZKKMGJJVCIBAEA3DMHYO74
Firmware version: v1.0.6
USB API version: 1.1
Flash UID: 0000000000000000
@ConceitedCode That looks as expected. Hardware version detection is working on your board. What problem are you having?
I wasn't able to connect using the cynthion
cli tool until I flashed the experimental firmware you provided above. It showed a "backend not available" error when running any commands.
Updating to the experimental firmware you provided above resolved the immediate issue. Just making sure it won't have a problem if I update the board later like you mentioned above 🙂
Side note - Is my flash UID supposed to be all 0's?
That sounds like https://github.com/greatscottgadgets/cynthion/issues/136, not like this issue. I don't think the experimental firmware itself had anything to do with solving "backend not available", though perhaps something you did along the way affected pyusb's ability to find libusb.
The flash UID is a known bug: https://github.com/greatscottgadgets/cynthion/issues/125
I think that firmware should work fine for you. However, things will likely break again the next time you do a firmware update. I suspect that there is hardware failure preventing automatic hardware revision detection. Can you please show me the output of this test program?
#!/usr/bin/env python3 # # for use with experimenatal firmware only from apollo_fpga import ApolloDebugger import usb d=ApolloDebugger(force_offline=True) reading = d.device.ctrl_transfer(usb.ENDPOINT_IN | usb.RECIP_DEVICE | usb.TYPE_VENDOR, 0xff, 0, 0, 2) print((reading[0] << 8) + reading[1])
3266 3268 3265 it seems to vary slightly, which makes sense since you said it's an adc
Thank you! That is great information! Those numbers are only slightly outside the expected range, so we may be able to fix this in firmware, though we would also need to widen the designed range in future revisions.
@nsluhrs This should be fixed for you in the next release of Apollo and Cynthion.
Hello, my device is reporting an incorrect hardware revision.
This seems to lead to the flasher not finding the right bitstream causing update to not work.