I'm trying to upload my build code to my alchitry-CU FPGA board threw apio using iceprog on windows.
apio upload
which then executes
iceprog -d i:0x0403:0x6010:0 hardware.bin
And the output is
init..
Can't find iCE FTDI USB device (device string i:0x0403:0x6010:0).
ABORT.
scons: *** [upload] Error 2
I have installed the libusbk driver and also tested uploading with the same cable on another pc with the standard drivers and the provided IDE Alchitry Labs in combination with iceCube2 but I really wanted to use the open source alternative instead.
Never mind I found the fix. The problem was that the Alchistry CU shows up as two different devices in Zodic when installing the drivers, one as Interface 0 and one as Interface 1 and I didn't see the other one and only installed the libUsbK driver on one of them.
Related
Overview
I need to program a recently purchased STM32F407ZGT6 board
In 'normal mode' my computer doesn't recognizing the board as a Ports (COM & LPT)/STMElectronics Virtual COM Port when connected via USB (I'm using a Windows 10 Pro). The LEDs turn on and I can get it into 'DFU mode'. When I try to debug the code, I get the "No ST-LINK detected!" message in either mode.
This is my first time connecting the board and also my first time dealing with STM32
Despite the instructions, I want to program the board using C directly from the STM32CubeIDE
Here is what I found
I found this question [1] where Device Manager reads the STM as Disk drives/STM32. My PC identifies it as mass storage and portable devices on Windows 10 Pro. When in DFU mode, I can see it as Universal Serial Bus Device/STM32 BOOTLOADER on Device Manager.
The tutorial [2] uses Flash Loader Demo and this older tutorial [3] uses STSW-STM32080, but both of the drivers are tagged as obsolete on the ST Website. STM32CuberProgrammer is indicated instead, but I would like to flash and debug directly from the IDE. Another forum reply [4] says that "you need a ST-link V2 programmer to program the brand new chip".
In summary
I can see the solution being one of the following options:
correct answer I need to use the ST-LINK-V2 to program from the IDE and that's the only way
I need to flash a bootloader via STM32CubeProgrammer to get it to work via IDE (is there a standard code for this?)
I have to build the cross-compiler for MicroPython [5] before I get to program it in C
What are your thoughts? Any other driver or idea that I might be missing?
Update
I went on and got my hands on a ST-LINK V2. I made the connection via the JTAG/SWD connector (see schematic) and I also tried connecting directly with the pins:
ST-Link
JTAG/SWD
Pins
SWCLK
9
PA14
SWDIO
7
PA13
GND
10
GND
3.3V
1
3.3V
RST
3
PB4
The ST-Link is not recognized. The ST-Link blinks and the board is powered up, but that's it. Device manager before and after shows the same.
So I went on checking if I was missing any new driver/program. I installed the STSW-LINK004 (STM32 ST-LINK Utility v4.6.0.0) based on these instructions, but no luck, Utility cannot find it either. I've reseted the computer after each driver installation. If I connect my boardvia USB in DFU mode, it is still recognized as STM32 BOOTLOADER, if I do it with the ST-Link, nothing changes.
Update solution
It turned out the ST-Link was faulty and therefore not connecting. After finding another ST-LINK/V2, the computer can recognize the board under Universal Serial Bus devices/STM32 STLink.
Debugging with STM32CubeIDE will always need an ST-LINK or other JTAG or SWD debug probe.
The bootloader allows you to program the microcontroller with a binary image, and that's it. The IDE will happily produce such a binary image, and possibly even have a wizard for transferring it via DFU. But that's only programming, no debugging And only be when the bootloader is running. If you did debug-like things like reading RAM contents, you'd get what the bootloader stores there while it is running, not the variables that your own program uses.
The ROM bootloader supports several ways of receiving new code to flash -- USB (DFU), CAN, I2C, SPI, UART. That last is not a USB Virtual COM port, it is honest-to-God UART using the USART peripheral in the microcontroller and RX/TX pins.
If you want a virtual COM port for your custom firmware to use to send data to the PC, you have to program the USB peripheral.
I created an small embedded WinUSB device which offers 2 bulk endpoints. This device can communicate with Linux and with Windows10 without installing driver, or a .inf file.
Now we want to use the same API with a embedded Linux. The USB-Gadget mode offers Serial CDC/ACM and RNDIS-Ethernet and many more.
I was able to create a USB-Gadget with the gadgetfs which had only bulk ep. I could communicate with Linux and Windows host. The USB-Device had /dev/ttyGS0 to communicate. But in Windows I had to install WinUSB driver manually.
I work with yocto to create embedded kernel.
I added some line of code here: /linux-imx/drivers/usb/gadget/legacy/serial.c , f_serial.c, u_serial.h to add additional variable os_desc and parameter use_winusb. But the resulting g_serial still creates a COM-Port in Windows10 or a no WinUSB device. For our device we need WinUSB-Device only.
The RNDIS Gadget does has WinUSB support. So I tried to create a own USB-Gadget device with https://github.com/libusbgx/libusbgx. But if I use the USBG_F_SERIAL function type then it can't create WinUSB. See error:
Error setting function OS desc
Error: USBG_ERROR_NOT_FOUND : Not found (file or directory removed)
If I use USBG_F_RNDIS, it works, and with manipulated USB descriptor it'll recognized by Windows as WinUSB device. But Linux implement's it as USB-ETH ethernet device. The USB-Device get's no /dev/ttyGS0 serial connection to communicate.
I'm reading the Linux kernel driver source now, to find the position, where I can simply ann this WinUSB os-descriptor stuff into the USBG_F_SERIAL type. But I think it'll take month to get through.
Any solution would be ok. Patch for the Linux driver sources g_serial or how to configure a USB-Gadgetfs would be great. Any hint, where to put additional code would also be fine.
I wanted to change the kernel, but fortunately found this:
https://blog.soutade.fr/post/2016/07/create-your-own-usb-gadget-with-gadgetfs.html
This code made it easy to add WinUSB features.
Source of modified Version for WinUSB: https://github.com/rundekugel/gadgetfsd/tree/WinUSB
I'm trying to use CSR BlueFlash to dump the firmware/upload new firmware to a JBL Flip 3 speaker. I've put the speaker into DFU mode and it shows up in the OSX ioregistry (see below):
but when I try to run BlueFlash, no USB devices are found. Looking in ~/.wine/dosdevices, there are no COM<number> symlinks. In fact, I don't believe there are any /dev/tty devices corresponding to the USB device. I've tried many different USB port numbers (like idProduct and bcdDevice) but BlueFlash finds no USB devices with that number.
I have seen a project where someone got BlueFlash to recognize the device with a JBL Flip 4 so I am fairly certain that what I am trying to do is possible.
Does anyone know how to get Wine on OSX to recognize a USB device?
Finally the sparkfun board edge boards arrived today ;-)
Following this well written guide : https://codelabs.developers.google.com/codelabs/sparkfun-tensorflow/#3 i am stuck with the following NoResponseError when trying to flash the code on the Ambiq, with the uart_wired_update.pyscript, that comes with tensorflow examples
opprud$ python3 tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py -b 115200 /dev/cu.usbserial-1430 -r 1 -f main_nonsecure_wire.bin -i 6
MOJ/Connecting with Corvette over serial port /dev/cu.usbserial-1430...
Sending Hello.
No response for command 0x00000000
Traceback (most recent call last):
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 336, in <module>
main()
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 38, in main
connect_device(ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 58, in connect_device
response = send_command(hello, 88, ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 235, in send_command
raise NoResponseError
__main__.NoResponseError
My setup:
Macbook pro, tried both old 15" & new 13"
Sparkfun serial basic breakout, USBC version (default jumped to 3v3)
FTDI 3v3 serial cable
I have tried
two different edge boards, with the correct Key14 & reset combo + misc variants and timing
legacy USB on old Macbook
new Macbook w USB C
FTDI 3v3 serial cable as alternative to sparkfun serial board
Running an alternative uart_boot_host.py script in tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/bootloader_scripts/uart_boot_host.py, also no response
I can measure, with a scope, the handshake bytes '0x14', '0x55', '0x9d', '0xe9' '0x0', '0x0', '0x8', '0x0' being transmitted initially at 115200 on the TXO pin on the programming header - but the ambiq is not replying anything.
btw. The onboard demo is running, blue led flashing, an some "yes's" are being recognized.
Any inputs welcome.
Does anyone know the protocol for the corvette bootloader ?
Are there any CPU revision changes from the first batch of boards, or possibly any lock bits programmed accidentally from sparkfun ?
rgds from an eager TF lite user ;-)
I tried measuring the actual baudrate with a scope on rx/tx pins, and saw that the bit timing using default OSX serial driver is rather imprecise, app 10% off, causing faulty readings, and ultimately missing bytes, when the baudrate are high.
After updating to the ch340 serial driver, timing improved, and the bit timings were correct.
At 921600bps, a single byte 8N1 is supposed to be10.9uS
Driver install
https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver
This is what worked for me: (source: github.com/sparkfun/SparkFun_Edge_BSP/issues/3, the SparkFunEdge tutorial and my teammates!). I am running this on a Linux machine (x86_64; Run $ uname -a) and my SparkfunEdge DEVICENAME=/dev/ttyUSB0
The tutorial does warn you about this problem at Step 4:
Note: Some users have reported issues with their operating system's
default drivers for programmer, so we recommend installing the
driver before you continue.
Click on the driver link and follow the instructions under "Other Linux distributions" as follows:
Install the correct version of the ch34 library.
$ git clone https://github.com/juliagoda/CH341SER.git
$ cd CH341SER/
$ make
$ sudo insmod ch34x.ko
$ sudo rmmod ch341
To verify that the correct driver is being used, run:
$ dmesg
..
[889247.585301] usb 1-7: ch341-uart converter now attached to ttyUSB0
[955698.718839] usbcore: registered new interface driver ch34x
[955698.718848] usbserial: USB Serial support registered for ch34x
[955759.196437] usbserial: USB Serial deregistering driver ch341-uart
[955759.196576] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[955759.196601] usbcore: deregistering interface driver ch341
[955759.196643] ch341 1-7:1.0: device disconnected
Now unplug the USB-C from the SparkfunEdge Board, and plug it back again
$ dmesg
....
[955876.176950] ch34x 1-7:1.0: ch34x converter detected
[955876.177320] usb 1-7: ch34x converter now attached to ttyUSB0
glad to hear that you're so excited about the board. I have a hunch that this will be an easy fix.
The Edge boards handed out at the conference have a bootloader set for 115200 baud, however the Edge boards that have come out in the second batch are upgraded to flash at 921600 baud, greatly reducing flashing time. Try changing the baud rate in your serial upload script.
You can also set up the Ambiq Software Development Kit to write your own applications for the Apollo3 microcontroller. Check out the tutorial here: Using the Edge Board with Ambiq SDK
Since I can't comment on your post (not enough reputation.... thanks SE) I'll be responding here.
If the baud rate accuracy is a problem I'm slightly unsure that that would be caused by the OS, but rather I'd think it is a problem with the USB-serial converter chip. I've been using the CH340G whereas on the USB-C version there is the CH340C IC. The difference between the two is that the "C" version includes an internal oscillator to provide the frequency reference. It is possible that that one is less accurate...? I'll try it out over here (but on windows) and let you know.
If this is a persisting problem would you mind making a post on the SparkFun forums? That way our tech support can get linked in (they are the people who could get you replacement hardware in case it is defective, also). Here's a forum for the Edge: SparkFun Edge Forums
If the problem is coming from the OS then the only fix that we can do with the Edge is to reduce the bootloader speed. We're working on a short tutorial about how to do that, but it would require having a programmer/debugger for Cortex-M processors. The Ambiq Apollo3 Evaluation Board has a built-in SEGGER J-Link which is what we used to program the boards.
On MacOS Mojave, Installing/Reinstalling CH340 works for me:
https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers#mac-osx
Before doing install, check that you actually see the sparkfun edge device with:
ls -l /dev/cu*
If driver is correctly installed, you should detect:
/dev/cu.wchusbserial1420
I got similar issue whereas I only had /dev/cu.usbserial-1420 and thought that was expected device to access, whereas it is /dev/cu.wchusbserial1420 which was only detected after installed ch340 driver.
Then flashing device works successfully for me.
Background info
WinAVR:
I installed WinAVR, and use avrdude.exe comes with WinAVR to download program into our board.
Adapter card:
We have an adapter card with FTDI4232 and AVR m328p on it. PC connects to FTDI4232 with a micro USB cable.
Schematic:
Sorry, I cannot post pics. So just describe the major part of schematic here. Two wires from(DATA_P & DATA_N pins) out from macro USB connector to DP[pin8] and DM[pin7] on 4232. And four wires(SCK, MOSI, MISO, SS_N) out from 4232 to m328p.
How to download program into the card before: Via pocket programmer. But we cannot give one pocket programmer to every engineer, so try to find out a way to download the program into m328p. Coz we have already had FTDI4232 on board, so this seems to be the best choice.
Can I download program via FTDI4232 on adapter card?
I know there is dedicated programmer based on 4232 chip, but this is our own design, I am not sure we can do it or not according to the above schematic.
what I did
Run this command:
C:\WinAVR-20100110\bin\avrdude.exe -c 4232h -p m328p -U flash:w:\Desktop\work\a_card\WinAVR\blink\blink.hex:i
But got the following error:
avrdude.exe: Error: no libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again.
Then, download the compiled libftdi package from this link:
https://code.google.com/p/picusb/downloads/detail?name=libftdi1-1.0_devkit_mingw32_17Feb2013.zip
, and extract it as “compiled_libftdi”.
There is not too much info about how to use this compiled package, so I just found info online.
(1) I installed WinUSB driver for the first two ports of 4232 by Zadig. I can choose one port in the drop down menu, then choose “WinUSB(v6.1,7600…)”, “Install WCID Driver”.
(2) Then, enter into the “compiled_libftdi” folder, run “find_all”, I saw:
Number of FTDI devices found:1
Checking device: 0
Manufactureer: FTDI, Description: USB <-> Serial Converter
I think it means the USB driver for libftdi package installed successfully.
Run the above download command again, still failed.
I thought maybe because the avrdude.exe is out of date. So download a .exe from here:
http://download.savannah.gnu.org/releases/avrdude/avrdude-6.0.1-mingw32.zip
And replace the old one in the WinAVR folder.
Still got the error, but got one extra line info:
avrdude.exe: programmer operation not supported