I bought an Au v2 board, because i wanted a recent board with a serie 7 FGPA for Embedded purpose programmed in C that could be exploited via Xillinx tools.
I wanted to put my bit stream + a bootloader + my C Embedded code into the QSPI chip throught the Vitis Unified IDE’s tool… like i did with my Agilent CMOD A7 35T board.
I’didnt succed this operation because this SPI flash isn’t supported by Xillinx and i didn’t thought to check this feature… my bad !
So i want to try something, swap the actual SPI flash with a compatible one with the same features but supported by Xilinx.
I choose the MX25L3233F in 8-WSON, wich is almost the same form factor that the 8-WDFN of the microchip SPI flash.
I’ve checked the pinout from the schematics of the Au V2 and the CMOD A7 35T, there is no big differences so it’s a GO for me.
You will need a heat gun for this, not because the chip is glued, but because the WDFN have a large ground pad under the chip.
So you will have to protect all the surrounding components with kapton tape and be carefull not pushing anything else.
This will be some tricky surgery XD
Indeed, i’ve read in the data sheet ( from the MX25L3233F) this:
Blockquote
This package has an exposed metal pad underneath the package. It is recommended to leave the metal pad floating or to connect it to the same ground as the GND pin of package[…].
I would like to use hot tweezers, but if you say the exposed metal pad is soldered… I will go for the heat gun with kapton tape.
You 100% need to use hot air. I think you can get away with not using tape (I never have) but YMMV. The parts around the flash will likely stay put due to surface tension.
You probably won’t be able to use the Alchitry Loader/Labs to program the flash after switching it out.
We don’t use one of the supported flash chips because of how much faster the one we use is to program.
I really do wonder if this is a good tradeoff? I don’t know about you, but i am, effectively, doing a hard flash of my design onto the Au approximately 0% of the time from Vivado. I just load to RAM. In terms of the total amount of invested time regarding uploading a more persistent image via proper flashing- It takes me hours, days, weeks to get to a checkpoint worth doing as a persistent flash image. Why, exactly, would I care whether that incredibly infrequent full flash imaging took an extra minute?
I know it’s the kind of thing that is unlikely to change at this point (I mean, oh god, how would you deal with the existing installed base if you changed the flash at this point?), but this is a serious question, mostly because I think it has an interesting answer.
I personally use the flash all the time. There are some things that I have to power cycle or move the board to after programming and it needs to be persistent. The current flash chip takes something like 10 seconds for a full program (a few ms for an erase). The supported ones are something like 70-100 seconds for a full program.
I’m open to hearing more opinions about it if other people feel the same?
Support for more than one flash chip is not only possible but we already have done it in the past. The bridge code just ID’s the flash then acts accordingly. It could be done to support another chip.
For what it’s worth, the supported slower chips are much cheaper so I’m not opposed to them
Also the Pt+ (200 gate version, not out yet) will have to use a different flash chip as the one we use now doesn’t come in a large enough size.
I’m like Jflanagan and i use a persistent image on SPI flash from time to time.
Since i use my CMOD A7 35T from Digilent, the amount of time to erase/flash is quiet acceptable.
I don’t have much different FPGA board so i don’t have enought feedback.
From the other side, i understand that if you flash every time then you need a speedy SPI flash.
I will see how much time it takes to flash my SPI flash, but it’s less than 70 secondes, maybe it depends if it’s fully or partially written on the flash.
Handling different harware conf for a same board isn’t simple.
Finally, I do not complain about the board which is very fine, i complain about myself to not be enought experienced to choose well a board.
Hi all,
Apologies in advance if this is stupid I’m only a hardware person -Yes the heat gun method would be tricky but would probably work if you are very careful and not pull tracks off the PCB by over heating things. My question is why change it to another device anyway? If the protocol used to program the devices and the pinout are the same? Why not just change the the ID header in the existing device to one that is supported by Vivado and program it from there.
Mike
Hello, Is there a workaround to use Vivado to burn the Microchip SST26VF032BT-104I/MF flash that is on the Au V2 board. It looks to be command level compatible with Infinion QSPI flash. Is there a way to tell Vivado to ignore the wrong JEDEC ID code and proceed? My Au V2 board came pre-programmed. How was the flash programmed by Alchrity? What is the trick?
Well, I installed alchitry-labs and alchitry. I was able to use alchitry-labs to create a project and burn it into the configuration flash. I have not determined how to take a .bin file from Vivado and burn it into the board. I tried using “alchitry load” with various options but it says it does not find the JTAG cable. I was able to use Vivado to download and debug directly to the FPGA.
Are there instructions on how to use alchitry to burn a .bin file into the AuV2?
I also tried achitry-labs and selected the Loader option.
$ alchitry-labs
USB error 5: unable to claim usb device. Make sure the default Ftdi driver is not in use: Entity not found
org.usb4java.LibUsbException: USB error 5: unable to claim usb device. Make sure the default Ftdi driver is not in use: Entity not found
at com.alchitry.labs2.hardware.usb.UsbDevice.<init>(UsbDevice.kt:94)
at com.alchitry.labs2.hardware.usb.UsbDevice.<init>(UsbDevice.kt:10)
at com.alchitry.labs2.hardware.usb.ftdi.FtdiLibUSB.<init>(FtdiLibUSB.kt:14)
at com.alchitry.labs2.hardware.usb.UsbUtil.openFtdiDevice(UsbUtil.kt:103)
at com.alchitry.labs2.hardware.usb.BoardLoader$Companion.erase(BoardLoader.kt:67)
at com.alchitry.labs2.windows.ComposableSingletons$LoaderKt$lambda$1575472450$1$3$3$2$1$1.invokeSuspend(Loader.kt:137)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:124)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:586)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)
Failed to open board!
```
USB error 5: unable to claim usb device. Make sure the default Ftdi driver is not in use: Entity not found
org.usb4java.LibUsbException: USB error 5: unable to claim usb device. Make sure the default Ftdi driver is not in use: Entity not found
at com.alchitry.labs2.hardware.usb.UsbDevice.(UsbDevice.kt:94)
at com.alchitry.labs2.hardware.usb.UsbDevice.(UsbDevice.kt:10)
at com.alchitry.labs2.hardware.usb.ftdi.FtdiLibUSB.(FtdiLibUSB.kt:14)
at com.alchitry.labs2.hardware.usb.UsbUtil.openFtdiDevice(UsbUtil.kt:103)
at com.alchitry.labs2.hardware.usb.BoardLoader$Companion.load(BoardLoader.kt:87)
at com.alchitry.labs2.subcommands.LoadProject$execute$4.invokeSuspend(LoadProject.kt:107)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:263)
at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:94)
at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:70)
at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:48)
at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
at com.alchitry.labs2.subcommands.LoadProject.execute(LoadProject.kt:105)
at kotlinx.cli.ArgParser.parse(ArgParser.kt:657)
at kotlinx.cli.ArgParser.parse(ArgParser.kt:530)
at com.alchitry.labs2.CLIKt.main(CLI.kt:33)
OK, I find that running Xilinx tools like the Vitis SDK causes the Alchitry Loader to malfunction. I did a complete reboot of my linux machine and the loader was able to burn my .bin file into the flash. Burning the configuration flash on the Alchitry Au V2 is just a little tricky.
