New Alchitry Cu on macOS

Is there any way to flash from with Alchitry Labs on macOS? I just got my Alchitry Cu from SparkFun today and the Load Flash icon never lights up. I noticed other people talking about alchitry_loader on the forums, but it does not natively compile on macOS. I forked it and updated the CMakeLists.txt and added the ftdi driver lib and headers to be able to build it. Is that something that I should make a PR to go back to the main repo?

macOS Arm64 Alchitry Loader support

I can use my Windows box or a Linux laptop if that’s easier but I do love my MacBook Pro.

Thanks,
Steven

It should work on macOS. I’m not a Mac guy so I can only give limited troubleshooting advice. I’ll have to fire up my Mac Mini if you need more help tomorrow.

Check the obvious things like that your USB cable has data lines. You’d be surprised how often that’s the issue. Does the device show up when plugged in? (does Mac have an equivalent to Window’s device manager or lsusb on Linux?)

The data cable should be good. It’s an Apple USB-C to USB-C USB 2.0 rated cable. The Serial port shows up and it is detected as Alchitry Cu.

/Applications/Utilities/System Information.app will display USB devices. On the command line you can use ioreg -p IOUSB or system_profiler SPUSBDataType to display USB devices.

system_profiler:

❯ system_profiler SPUSBDataType
USB:

    USB 3.1 Bus:

      Host Controller Driver: AppleT8132USBXHCI

        YubiKey OTP+FIDO+CCID:

          Product ID: 0x0407
          Vendor ID: 0x1050
          Version: 5.43
          Speed: Up to 12 Mb/s
          Manufacturer: Yubico
          Location ID: 0x02100000 / 1
          Current Available (mA): 500
          Current Required (mA): 30
          Extra Operating Current (mA): 0

    USB 3.1 Bus:

      Host Controller Driver: AppleT8132USBXHCI

        Alchitry Cu:

          Product ID: 0x6010
          Vendor ID: 0x0403  (Future Technology Devices International Limited)
          Version: 7.00
          Serial Number: FT4MG9OV
          Speed: Up to 480 Mb/s
          Manufacturer: Alchitry
          Location ID: 0x00100000 / 1
          Current Available (mA): 500
          Current Required (mA): 500
          Extra Operating Current (mA): 0

    USB 3.1 Bus:

      Host Controller Driver: AppleT8132USBXHCI

ioreg:

❯ ioreg -p IOUSB
+-o Root  <class IORegistryEntry, id 0x100000100, retain 35>
  +-o AppleT8132USBXHCI@02000000  <class AppleT8132USBXHCI, id 0x10000043d, registered, matched, active, busy 0 (1872 ms), retain 71>
  | +-o YubiKey OTP+FIDO+CCID@02100000  <class IOUSBHostDevice, id 0x100000be1, registered, matched, active, busy 0 (1865 ms), retain 81>
  +-o AppleT8132USBXHCI@00000000  <class AppleT8132USBXHCI, id 0x10000044d, registered, matched, active, busy 0 (4139 ms), retain 84>
  | +-o Alchitry Cu@00100000  <class IOUSBHostDevice, id 0x100340ea7, registered, matched, active, busy 0 (86 ms), retain 41>
  +-o AppleT8132USBXHCI@01000000  <class AppleT8132USBXHCI, id 0x10000043b, registered, matched, active, busy 0 (3019 ms), retain 77>

I am a Mac guy. I am not an FPGA guy yet, but I write C++ for iOS and Android apps all day long. I can poke at anything you need me to poke at, or figure out how to build the Kotlin project with a debugger attached if it would help.

alchitry_loader does work on the command line:

❯ alchitry_loader -b 0 -t cu -f alchitry_cu_v2.bin
Found Alchitry Cu as device 0.
Resetting...
cdone: low
flash ID: 0xEF 0x40 0x16 0x00
Programming... Done.
cdone: high
Done.

So I was able to flash my first FPGA! Woo. Would be nice to be able to do it from the Alchitry Labs though.

What is weird is the LEDs blinking are not the same as in the simulator:

    always {
        reset_cond.in = ~rst_n  // input raw inverted reset signal
        rst = reset_cond.out    // conditioned reset

        led[7-:2] = c{my_blinker.blink, ~my_blinker.blink}
        led[5-:2] = c{my_blinker.blink, ~my_blinker.blink}
        led[3-:4] = c{rst, rst_n, rst, rst_n}      // connect rst to the first LED
        
        usb_tx = usb_rx         // echo the serial data
    }

What I expected is the is leds 7 and 5 to blink opposite 6 and 4. Then I expected leds 3 and 1 to light when pushing rst and leds 2 and 0 to be illuminated all the time.

What I see is only leds 2 and 3 blinking back and forth then leds 3 and 1 illuminating with the rst button push.

I figured out why I could not flash from within the app. I mistakenly was using the Cu 2 because I didn’t realize that I could scroll and select the original Cu for this particular board. That all seems to be working fine now, but the weirdness with led 0 and 5 still remains. They do not blink when I use the All Blink demo program. When I connect my IO v1 board the demo count on the 7 segment display looks all kinds strange. :frowning: Hopefully I didn’t screw up the board by flashing the wrong version code to it a couple of time.

Hmm. I picked up the board Cu again while typing this and now LED 5 was blinking, but it has since stopped again. Did I mess this board up?

The pin assignments changed between v1 and v2 on the Au. I expect it’s quite likely they changed on the Cu as well. Alchitry Labs attempts to insulate the user from that detail. My guess is that somehow you’re using the wrong version of the constraint file, which is where the pin mappings happen.

It seems rather unlikely you damaged the board. I just checked the schematics and you would have just been trying to blink pins on the headers.

Try loading the attached bin file. I tested this on my Cu V1 and it blinks all the LEDs. You can use the loader (click the beaker logo → switch to Alchitry Loader) to program it.
alchitry_cu.zip (1.1 KB)

You could try to apply a little force on the FPGA chip/flex to the PCB to see if maybe it has a bad solder joint that is causing it to be intermittent. If it works, then it’s likely that and you should contact SparkFun for a replacement.

That’s what I was afraid of.

Blinky Video

If I bend the PCB gently upwards the LEDs that do not flash will start to blink, but after releasing tension they go back to not lighting.

Thanks for the help. I have reached out to SparkFun and fortunately, I have a Cu V2 coming on Monday via USPS so I shouldn’t be without for too long.

For what it’s worth, the V2 boards are all x-rayed and the GPIO are all tested for continuity and shorts making this kind of defect much less likely to make it through.

I received the v2 board today and it is working 100% as expected. Still waiting for SparkFun to respond about the v1 board, but at least I can move on with learning now.