Dude you ROCK!
moefear85 opened this issue · comments
where can I donate??!!
Seriously I've been head banging for weeks... trying to get a working USB-UART bridge, given that CH340g board seems to have electrical problems thus garbling all its TX, and replacement FT2232 is a long way from arriving.
I've tried other projects, only to find that the buffers overrun after 30 bytes. I tried myself, but gave up short of figuring out how to read the dtr/rts pins from USB (which is the whole point). Then I finally got your binary flashed. It didn't work the first time, so I lost several days, until I realized my stm32f103c8t6 boards (11 in total), were a mix of various clones. 5 were secretely stm32f103c6, and 3 were 128kb variants, and almost every one had its own set of codes printed on the MCU chip itself. I finally figured out which was vanilla, and now it works like charm!
Technically, so satisfy the category of "issues" (so nobody bites my head off), I'd like to mention its important to disconnect the ST-Link before testing the board, otherwise the LED will blink, but still no communication will happen. That one almost made me give up at the last breath.
Thank you for the nice words, you've made my day! :) I appreciate your feedback a lot. I'm really glad you figured out how to get this thing up and running on your hardware and didn't give up :)
I also use stm32f103c8t6 MCUs, which I believe are clones. I bought them on AliExpress. They have 128k flash, but the firmware ignores this fact and occupies the first 64k only. I think the flash size should not be a problem. The most common problem with the blue pill boards is the wrong USB D+ resistor value. I'm not sure if it applies to your situation, but just in case, please see Fixing USB on Blue Pill Boards for more info. It would be great if you could share more details on 128k MCUs that didn't work. Board pictures, hardware IDs, all that stuff would be helpful. We'll see if we can make them work, or at least I can improve the documentation.
The issue with ST-Link is also a little bit surprising. The thing is, I always have my ST-Link v2 (again, I believe it's a clone) connected to the board while developing and debugging the firmware. Sometimes it is needed to perform a hardware reset or cycle the power after flashing. It usually happens when I reflash the board, which is already flashed and connected to USB. But then it works just fine. It would help if you could share some more info on that (the board you use, your ST-Link version, the way these two guys are connected, etc.).
Last but not least, I've never thought of collecting donations before, but since you asked, I've added a Buymeacoffee button to README.md :)
I just tried flashing an esp8266 on linux... Unfortunately it didn't work... The chip isn't being properly set into the boot mode. Do you perhaps have insight into the issue? I didn't check the RTS/DTR Pins with a multimeter/oscilloscope yet, but intend to soon... I'm using Fedora 34. It would be awesome to be able to program/printf-debug several mcus at once with the bluepill, being independent of more expensive usb-to-serial converters.
I would also like to upload pictures of the various stm32 boards I have... in case they are useful to others who face problems... but don't know how to do this in Github? I'll upload them as files into my own repo i a while...
As for ST-Link, I also use one I bought off ebay. I believe internalls it's an stm32f103c8t6 programmed as an st-link. unfortunately no documentation.
Hi, unfortunately I don't have any experience with esp8266. I guess we should wait until you can check RTS/DTR with a scope. Please keep in mind that you can invert them using the configuration shell (see README.md) in case it is needed for esp programming.
I am looking forward to seeing those board pictures. I guess I can use them to improve documentation a little bit.
As for ST-Link, mine comes from AliExpress. And yes, there is an stm32f103c8t6 inside. I only connect SWCLK, SWDIO, GND, and 3.3V lines. I don't use RST and maybe this is the reason why it works in my case. Cannot check it right away.
-
I uploaded 2 pictures of stm32 just now... but I realized it's too difficult to get legible quality with my camera, so I stopped. One is a 64kb version, the other 32.
-
Esp8266 isn't specifically necessary. Have you ever successfully tried automatic flashing to another bluepill using the monster? Does it work on linux? Either way, I intend soon to study your source code, if I can't get it to work... I'll try the pin flipping if necessary. Uptil now I haven't been able to get any prompt. The led used to flash when I hooked PB5 to ground, but recently it stopped. Unfortunately, I'm busy at the moment getting esp8266 programmable using pymakr over wifi. I just uploaded a script that I recently finished. I'm working on expanding its features right now, since it allows remote automatic flashing if successful.
I did flash another blue pill via serial port with bluepill-serial-monster. It worked just fine, but I was on mac. I tested bluepill on Linux as well, but I did not flash other bluepills on Linux.
I just tested the configuration shell with the last version of firmware on macOS and Ubuntu 20.10. Everything works OK. Also I tried flashing a blue pill board via the serial port using bluepill-serial-monster and stm32flash on Ubuntu. That also worked. Flashing stm32 via the serial port does not require using anything except for RX/TX pins, so RTS/DTR were not involved.
I'm not sure I get the question. With stm32 I don't have to do anything with DTR in order to get it programmed, so I don't have this issue. But then again, my programming scenarios are fairly simple. If I were to do this and the programming software wasn't capable of controlling DTR/RTS itself, I would probably write a python script or a small C program to set the control lines the way I want.
OK, I see. I usually flash stm32 with st-link, which I also use for debugging, so I don't normally have to deal with boot jumpers. As far as I know boot 0 and 1 are active high signals, while RTS/DTR are active low by default. So setting them to high will actually set boot 0 or 1 to low.
Ok.... So I did further testing.... The board is working as advertised :P Automatic uploading to esp boards seems to fail 1/3 of the attempts at the beginning of the connection, but that is either due to long cables, or noise in my setup. The success rate is high enough (just wastes 2-3 seconds to try again), and I'm reaching 1100Kb/s. The transfers always complete fully once started, indicating the issue is most likely reset pulse timing issues, which is not related to this project. Thx for the great work!
It does hurt a bit though that on UART1, only DTR is available (but works). Is there no way to remap RTS to another pin, even if done in software?
In fact, RTS pins are software controlled on all ports. The way RTS is implemented in stm32f103c8t6 does not work really well with the concept of DMA and large buffers. Initially, I did not implemented RTS on UART1 because there is no CTS pin available (it conflicts with something else and there's no meaningful remap). So I thought if I don't have CTS, I drop RTS as well to keep things simple. The concept where UART1 did not have flow control lines at all seemed more straightforward than having just RTS but no CTS. That may be wrong. On the other hand, I have a pretty busy pin map. I am not sure if I have any available pins for that. Please let me double-check this.
OK, I guess I can enable UART1 RTS on PA15. I believe your use case justifies doing that and dropping my original concept :) Would you be willing to test this?
yes sure! whenever it's ready... I have plenty of esp's waiting to do something... but on a side note... I just broke out a 128kb blue pill to test PB5... On the 64KB (I only tried 1 board), can't seem to get the help prompt working. PC13 sometimes blinks when I ground PB5, but either way... nothing.... I'll respond once I test this one... any clues on this? This one also doesn't respond to PB5, although it is being properly pulled up when not grounded. By UART1, you mean PA9 and PA10,r right? or is the help terminal on other pins?
Btw, I'm surprised this project is mentioned everywhere. It fully replaces any serial converter, while allowing simultaneously automatically reprogramming 2 or 3 MCUs simultaneously, consuming only 1 port, which is tremendously useful when trying to get multiple MCUs to work together or communicate together, and it supports any MCU that is programmable over serial, such as Arduinos, ESP-12, ESP32, and STM32. If USB-to-SPI and I2C support were added to it, it would fully replace ft4232 too!
oooooh ok.... Just a hint to anybody facing the same problem... the help console is on the USB side of UART1, not the serial side.
the help console is on the USB side of UART1
I guess it's my bad. I will improve the documentation.
whenever it's ready...
It is ready: https://github.com/r2axz/bluepill-serial-monster/suites/2974164740/artifacts/67079030 I did initial testing myself, seems to work OK. Please test.
Btw, I'm surprised this project is mentioned everywhere.
Is mentioned or is not mentioned everywhere? Initially, when I released the project, I tried to post about it wherever I could so people can find it, but I believe there is still a room for improvement regarding the project publicity. I would appreciate if you could help with that.
If USB-to-SPI and I2C support were added to it, it would fully replace ft4232 too!
I should think about this. Probably in a context of a different project. Just to keep the scope of this one as focused as possible.
i just realized you updated rts on uart1 a week ago. i will test it tomorrow... thx in advance
btw... i found instructions online on how to flash st-link v2 firmware onto any standard bluepill, i'll post a link later. it means in addition to the automatic serial programming using bluepill-monster, it is also possible to turn any number of available blue pills into st-link v2 programmers/debuggers, making it easy & cheap to concurrently debug any number of communicating stm32 boards.
i'll close this issue after speed testing uart1
just tested UART1.... it works perfectly, as if hardware dtr/rts.... With a little glue code, it's even possible to connect a monster to a PC over USB, and have instant access to 6 GPIO pins. Since only 4 are needed to bitbang SPI, one can then program an AVR/PIC using a blue pill. This modification wasn't even necessary to make that possible. thx for the great work!
Thank you very much for testing. I will merge #32 and create a new release.