(SOLVED) CH-340 USB to Serial Download issue

Geetings,

UPDATE: —-
It appears to be Linux driver issue.
Serial download worked fine on my XP box, but failed on Linux.
There is discussion about these CH340-based Chinese Arduino boards having similar
issue. The solution is to install a different driver supplied by the manufacturer.
They supply drivers for Windows, Linux and OSX.
I downloaded the Linux driver, built the driver and installed it.
Serial download now works fine with the new driver.
—-

Hope someone can help. This regards serial download method that fails with the CH-340.

I have a STM32F103VET6 board that includes a handy, on-board CH-340 USB to serial chip.
For some reason the STM32DUINO serial downloader appears not to like this chip. Please see console output below.

On further investigation, the board has jumpers to disable the CH-340 chip’s RX/TX and allow hardwiring in a substitute USB to serial convertor.
I substituted a PL-2302 based cable and found serial download is good and reliable.

Strange thing is, once good code loaded, one can change the jumpers back and the CH340 passes data back and forth over the serial interface just fine.

Does there appear to be a handshake issue at download time when the CH-340 chip is used? Or something with my IDE install?

Thanks in advance.
JBF.

—console debugging follows below————

ST32MF103VET6 with CH-340 USB-to-serial
—————————————————————–
Failed to read ACK byte <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Unexpected reply from device on command 0x01 <<<<<<<<<<<<<<<
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 230400 8E1

ST32MF103VET6 with PL-2302 USB-to-serial
——————————————————————
Using Parser : Raw BINARY
Interface serial_posix: 230400 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0414 (High-density)
– RAM : 64KiB (512b reserved by bootloader)
– Flash : 512KiB (sector size: 2×2048)
– Option RAM : 16b
– System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x08002034 (100.00%) Done.

Starting execution at address 0x08000000… done.

Have you tried STM’s Flash loader “Demonstrator” (i,e their serial flash loader) ?

You could also try reducing the speed, and if that fails there is a python version, but in both these cases you’d have to edit the serial uploader bat file (assuming you are running windows)

BTW. We have had various issues with the PC exe version, and I had to do several bug fixes, but not really any major code changes.
Unfortunately the source codes not seem to be supported by the original author either.

jbforrer wrote:
<…>
Strange thing is, once good code loaded, one can change the jumpers back and the CH340 passes data back and forth over the serial interface just fine.

Does there appear to be a handshake issue at download time when the CH-340 chip is used? Or something with my IDE install?

Thanks in advance.
JBF.

Thanks for the suggestions.

Incidentally, the board as described by @Madias in this post:
http://www.stm32duino.com/viewtopic.php?f=28&t=490
I need almost all those extra I/O pins for my project, more than the low-end Leaf clones offer.

1) I tried the “push reset” trick before download (am familiar with the procedure on my home-made Atmel Arduino projects). Did not help.

2) “STM Flashloader Demo” program does recognise the CH-340 and allows one to flash. I flashed the bootloader as example. Works fine.

3) Bootloader downloads via USB works fine, so does ST-link, also BMP works fine.

This is not really a showstopper for me as there are several working download methods, am just curious why there is this issue with the CH340 and not with some others, like for example, the PL-2303 USB to Serial interface. I can do as Ray suggest and use the on-board CH340 for serial I/O for my application, just not for serial downloading.

Appreciate the issues with the download code as mentioned by Roger… probably not worth wasting time on that.

Thanks much for all the efforts.
JBF.

I think that STMs Flash loader also has a CLI version, so you could also just modify the serial upload bat file to use the CLI instead.

The reason I didnt use the CLI was that I was trying to keep things as Open Source as possible.

If you have more than one STM32 board, you could flash the Black Magic Probe onto another board and use that for SWD uploads.

jbforrer wrote:
Incidentally, the board as described by @Madias in this post:
http://www.stm32duino.com/viewtopic.php?f=28&t=490

Please see the update on the first post regarding a solution.

Thanks,
JBF.

Thanks

jbforrer wrote:Please see the update on the first post regarding a solution.

Thanks,
JBF.

ahull wrote:
Do you have a link to the updated linux driver?

Interesting thread.

I was at the local makerspace last night and picked up a cheap Arduino clone that they were selling. I still have Yousemite on my laptop. Spent most of the time installing the driver. The first board failed to upload blink, the second worked. I basically wanted a burner Arduino. I was also curious about this bridge chip. I may pull parts off of the clone if the CH-340 is working. (It is likely the clone is missing a bootloader.)

sheepdoll wrote:Interesting thread.
<…>
I may pull parts off of the clone if the CH-340 is working. (It is likely the clone is missing a bootloader.)

As pointed out by @mrburnette, drivers can be downloaded from the manufacturer’s site:
http://www.wch.cn/download/CH341SER_EXE.html

Details are in Chinese. The Linux package contains driver source code (.cpp) and a Makefile.
Being Linux, one need to build a loadable module that will work with your specific kernel.

I understand some Linux distros might already have the correct driver. Plug the device into a USB port and check the list of kernal modules, i.e.,
>$ lsmod | grep usbserial.
If you find “ch341” is being associated with “usbserial”, that will be an issue with the CH-340 USB-to-Serial part and STM32duino serial download.

Unfortunately, still seems tricky to get the thing working properly. I’m no Linux expert so your mileage may vary. This what I found:
On my system, “make” fails due to incompatible “printk’s” sprinkled through the driver source. Guess these serve for debugging purposes.
Commenting all affected “printk” lines succeeded in building the driver, finishing with “ch34x.ko”.

Although the Makefile allows one to load/unload the new driver, one first need to unload the old driver, “ch341” otherwise it will clash with the new one, “ch34x”. There are various ways to clean this up, but be very careful how you proceed.

My kernel driver modules are in /lib/modules/3.13.0-24-generic/kernel/drivers/usb/serial … (you will likely have a different kernel).
“ch341.ko” was renamed “ch341.ko.OLD”, then the new driver copied in and named as “ch341.ko”.

Plugging the device into a USB port automatically loads the correct kernel drivers. Verify actions with “lsmod”, as shown below.
———————————-
$ lsmod | grep ch34x
ch34x 17618 0
usbserial 45014 1 ch34x
———————————–

Example results of a serial download:
Sketch uses 23,872 bytes (4%) of program storage space. Maximum is 524,288 bytes.
Global variables use 2,760 bytes of dynamic memory.
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 230400 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0414 (High-density)
– RAM : 64KiB (512b reserved by bootloader)
– Flash : 512KiB (sector size: 2×2048)
– Option RAM : 16b
– System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x08005d40 (100.00%) Done.

Starting execution at address 0x08000000… done.
——————————————————————

Hope that helps.
Best Regards.
JBF.

aren’t printk calls controlled by a writing a number to somewhere under /proc?

since i played with kernel code, when did the pci interface get a massive change 2.2/2.4/2.6?? eons ago – i had to
update/rewrite my pci device drivers. O’Reilly reissued their biblical tome on the subject, pretty sure they’re both on my bookshelf. updated since then as well. 3rd 2000 probably not, i’d moved on to a different project by then.

so i googled ‘linux kernel controlling printk output’

first 2
http://elinux.org/Kernel_Debugging_Tips
http://elinux.org/Debugging_by_printing
and the search drop down has in it /proc/sys/kernel/printk
yielding
http://man7.org/linux/man-pages/man2/syslog.2.html

stephen

I believe I have the same problem after I have tried many different combinations (TX/RX pins, PA9/10 pins, reset button, invert TX/RX that should not need to be inverted, 3.3 via USB TTL Adaptor, 3.3V via HID USB without HID USB, connected, et al).

A search did not turn up this topic my search about the problem I was having over last day of different attempt combinations I tried. I looked about where to post the issue. I thought USB to Serial adaptors would be where I place my question. I looked about and found this topic that I am sure matches what and why I have the problem I do.

The constant problem result:
Sketch uses 8828 bytes (13%) of program storage space. Maximum is 65536 bytes.
Global variables use 1984 bytes of dynamic memory.
Failed to init device.
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 230400 8E1

An error occurred while uploading the sketch

A quick update.

I looked for the ch341 driver:
ls -ls
total 44
36 -rw-r--r-- 1 root root 35398 Sep 12 2015 ch34x.c
4 -rw-r--r-- 1 root root 331 Aug 12 2015 Makefile
4 -rw-r--r-- 1 root root 531 Sep 12 2015 readme.txt


I found stm32flash Ticket#81 that may be helpful.

It appears to be a Linux related. Issue was on same machine bare metal Windows, Windows under VM of Linux, and Linux fine with the stm32 board in Windows and Arduino, then selected issues stm32 related in Linux. It appears the issue was related to Even Parity where suggestion to apply a Kernel patch that maybe did not make it to the mainline Linux Kernel. The OP for stm32flash Ticket #81 reported the suggestion to apply a Kernel patch resolved the problem of using stm32flash in Linux.

One notable difference is OP error for stm32flash Ticket #81 indicated Interface serial_posix: 57600 8E1

I managed to test the Even Parity Kernel patch noted in stm32flash Ticket#81. The Even Parity Kernel patch would not apply clean to the most recent CH340/1 source from chip maker. I took the ch340 source from the the Kernel and ran the Even Parity patch as dry run first and the Even Parity patch applied no issues. I applied the patch, compiled, unloaded original kernel ch340 driver, moved the ordigianl kernel driver out of the kernel modules tree, placed the new complied ch340 driver into the kernel tree and loaded the new ch340 driver.

Sadly the same problem Sketch uses 8828 bytes (13%) of program storage space. Maximum is 65536 bytes.
Global variables use 1984 bytes of dynamic memory.
Failed to init device.
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 230400 8E1

An error occurred while uploading the sketch