I got a generic board http://www.ebay.ca/itm/281670677060?_tr … :MEBIDX:IT
After some tests, I’ve been able to flash using usb-to-serial adapter.
When I plug it on my computer via USB, it sees a device 134f:0003 but I can’t seem to make it go in DFU mode.
When I press the reset button it does go for a few seconds (dfu-util -l sees it) but doesn’t stay. With BOOT0 jumper to 1, the device is not even recognised.
Is there a way to continue flashing using USB once the bootloader has been flashed via serial ?
Also, my goal would be to actually put http://www.fsij.org/category/gnuk.html on it, but I’m having issues figuring out the settings. Could anybody help me figure out ? Here is what I’m looking at : https://anonscm.debian.org/cgit/gnuk/ch … ree/board/
I see the VAL_* are basically the state to initiate the ports to, but I can’t seem to understand what value to use, or if the pin should be push-pull or open-drain or something else, and what to put in ODR.
Also, I can’t figure out how to set the USB, I understood that PA12 takes the place of the USB_DISC, but I can’t find what to do with the rest of the pins.
Thanks a lot,
Aurélien.
generic_boot_pc13 onto the board
https://github.com/rogerclarkmelbourne/ … 1/binaries
if you are using windows you then need to look in the drivers/win folder and run the bat file to install the DFU and serial drivers.
then put boot0 to Low
Reboot the board
it should appear as libusb, maple dfu in the device manager
(note it does not have serial while waiting for upload)
and first you must upload a blank sketch ( until you upload a sketch it does not have Serial)
BTW. To flash the bootloader, either download the flash loader from STM (windows only)
or use stm32flash from tools/win
stm32flash -w generic_boot_pc13.bin YOUR-COM-PORT
– installed the udev rules and restarted udev
– flashed the bootloader using stm32flash and usb to serial adapter:
stm32flash /dev/ttyUSB0 -w generic_boot20_pc13.bin
– put boot0 back to 0 unplug usb adapter, plug the usb cable on the board
now I see 1e4f:0003 usb device and it flashes.
Started the arduino IDE, with the settings:
Generic STM32F103C, 20k/128K (what dfu-util -l shows after the first flash)
and flashed an empty sketch:
Download [=========================] 100% 12124 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
I think you must me using OSX or Linux
If you are using Linux you need to either change the udev rules or device permissions, because by default Linux doesn’t let normal users accessing those USB devices
But I’m not an expert on Linux
You could try asking @ahull as he uses linux
Edit.
As I think you may be using linux, I’ve added the Linux udev rules and install script taken from the original Maple IDE for linux
see /drivers/linux in the repo
https://github.com/rogerclarkmelbourne/ … vers/linux
Note. I have not had chance to test these on a linux system yet.
I did install the udev rules though. Flashing the empty sketch worked once, but then when I tried to flash another sketch I get that the device is not dfu capable.
I’ll double check udev.
edit: udev seems fine
– dmesg
[ 1085.332175] usb 1-2: new full-speed USB device number 10 using xhci_hcd
[ 1085.461524] usb 1-2: New USB device found, idVendor=1eaf, idProduct=0003
[ 1085.461533] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1085.461539] usb 1-2: Product: Maple 003
[ 1085.461543] usb 1-2: Manufacturer: LeafLabs
[ 1085.461547] usb 1-2: SerialNumber: LLM 003
Is it normal ? Is there a way to force the board in dfu mode until reset ?
Thanks.
last week i wrote a utility (which works on OSX and may work on linux) which resets the board
you will need to compile this file
https://github.com/rogerclarkmelbourne/ … load-reset
e.g gcc upload_reset.c -o upload_reset
then copy the binary into /tools/linux
then modify the maple_upload script in /tools/linux so that it uses this utility to reset the board prior to calling dfu-util
if you look in
https://github.com/rogerclarkmelbourne/ … ple_upload
i changed the osx code
# ----------------- Old code to reset the USB - which doesn't seem to work --------
#
#if we can find the Serial device try resetting it and then sleeping for 1 sec while the board reboots
#if [ -e $dummy_port_fullpath ]; then
# echo "resetting " $dummy_port_fullpath
# stty -f $dummy_port_fullpath 1200
# sleep 1
## stty -f $dummy_port_fullpath 1200
## sleep 1
#fi
# ------------------ End of old code -----------------
# ----------------- IMPORTANT -----------------
# The 2nd parameter to upload-reset is the delay after resetting before it exits
# This value is in milliseonds
# You may need to tune this to your system
# 750ms to 1500ms seems to work on my Mac
${DIR}/upload-reset ${dummy_port_fullpath} 750
Thanks again for the help.
Aurélien.
I will push a change to the repo with the new files in it.
But at the moment I can’t get the Serial device to work at all under Linux. lsusb shows the device but I don’t think its being registered as a serial device for me ![]()
Just to confirm that it is also working under OSX. The only caveat for me is, that after I flash the bootloader to the board, I can access it via its onboard USB only if I connect it via a USB hub to my Mac. If possible, can you test it on your Mac to see if it only works via a USB hub?
Thank you! ![]()
With my 2009 MB Pro 13′ (core duo) I do not have such problems. A big fault was moving from snow leopard to mavericks… no older “arduino” based software (1.0x and below) worked anymore, evil enough with “real” hardware crashes (serial monitor) and reboots. This was caused because apple decided to use a own build generic driver for devices like FTDI.
The IDE actually resets my board itself and flashes the MCU. Thanks a lot !
using ubuntu 14.04, arduino 1.6.5 and this version of stm32duino (testing USB HID) https://github.com/libarra111/Arduino_S … 5670e27ee1
edit: my bad it seems I was able to flash once, but not after
Have you tried resetting the board just before the upload actually starts?
( this is a bit tricky on OSX as dfu util doesnt seem to have a very long timeout when looking for the dfu device)
I flashed a led blink, it worked. then I tried again, the device didn’t go in DFU.
I tried unplugging, reset, and flashing, but it doesn’t see the device in DFU mode anymore.
It might also be because I tried the USB HID, I’ll try with just serial next time.
EDIT: using the command line
arduino-1.6.5/hardware/Arduino_STM32_usb_hid/tools/linux/maple_upload ttyACM0 2 1EAF:0003 /tmp/build1842041194832510663.tmp/sketch_oct29a.cpp.binHow can I get COM port?
1) flash generic_boot20_pc13.bin
2) flash blank scetch (Generic stm32f103)
Bootloader is: https://raw.githubusercontent.com/roger … 0_pc13.bin
Arduino IDE says:
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
dfu-util: Cannot set alternate interfaceTry running it manually from the command line.
I had add a delay time to it, because dfu util on linux and osx does not wait very long, and some machines take more time to re enumerate than others.
Perhaps the best fix is to recompile the bootloader and put in a much longer delay where it waits while in dfu upload mode.
The current bootloader only waits a second or so, and perhaps a more reliable delay is 3 secs
look in main.cpp and config.h in the bootloader and you will see what you need to change
./upload-reset /dev/ttyUSB0 750
Failed to open serial device.The problem is that I did not select the right port in Tools->Port in the IDE when I changed Upload Method to “STMduino BootLoader”
Weird thing is that even if that is wrong BUT you manually reset the board with the right timing the upload goes fine.
But If I now use the right port it works properly, yep.
Weird thing: after having a run with a MapleMini for a confront about the path now when I plug the BluPill the kernel shows me a meaningful path for the BluePill too:
dmesg | tail
[30744.282491] usb 3-11: new full-speed USB device number 10 using xhci_hcd
[30744.411627] usb 3-11: New USB device found, idVendor=1eaf, idProduct=0004
[30744.411631] usb 3-11: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[30744.411633] usb 3-11: Product: Maple
[30744.411634] usb 3-11: Manufacturer: LeafLabs
[30744.411758] usb 3-11: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
That old chestnut
You are not the first person to be caught out by that one.
The IDE resets the board via its serial port,the Avr Adruino’s do the same thing, i.e use the serial port to reset the board but using the control lines, where as the stm32 bootloader uses both the control lines and also sends a magic character sequence
(the reset method was developed by Leaflabs, we just continue to use what they chose to use)
It looks similar to the MapleMini when you have to upload a first sketch and then it becomes to look like some sort of modem[1] like “cdc_acm 3-11:1.0: ttyACM0: USB ACM device”.
I tried to re-flash the bootloader but nothing changed, maybe it’s something related to the 1.5k ohm resistance hack for PA12 that makes it work erratically. I guess I’ll try tomorrow.
Thanks ![]()
EDIT: It’s the same issue as this user: viewtopic.php?t=331#p3285 : the reset works fine as long as I use a USB HUB, not a direct USB port. With a HUB I get a proper serial device, with my onboard USB3 / USB2 ports it’s erratic.
I feel like asking: why a 1.5k ohms resistor for the hack? Could a different value solve the issue it it’s power related?
However feel free to try different values. I think tried 4.7K and it worked. 2k definitely worked.
With the USB hub, I think they are intelligent, so it may not be the power that is the issue, it could be something else.
So yes 1.5k ohms is the target as for http://www.beyondlogic.org/usbnutshell/usb2.shtml – http://www.ftdichip.com/Support/Documen … ration.pdf –
The schematic of the boards http://www.stm32duino.com/download/file.php?id=276 claims 4.7k for R10 (which pulls up D+ to 3.3) but on mine it was a 10k: I just removed the SMD one and plugged in a 1.5k ohms resistor. Didn’t think to put a 1.8k in parallel, good tip, may come of use for my second board (I’m going to keep that as it is in order to have a safe – reference sample for debug)..
lsusb says that this is a 100ma device. Is there some sort of datasheet / specs for the board? Something like: http://leaflabs.com/docs/hardware/maple-mini.html . I’d like to gather some info for my students: http://wiki.piffa.net/index.php/BluePill . It would be nice to know how much current I can sink / source from it for starters. I’ve found the datasheet http://www.st.com/web/catalog/mmc/FM141 … 5/PF164494 for the uC that says something like:
Table 7. Current characteristics
Total current into VDD/VDDA power lines (source): 150ma
Total current out of VSS ground lines (sink): 150mah
Output current sunk by any I/O and control pin: 25ma
Output current source by any I/Os and control pin: -25mA
Output driving current
The GPIOs (general-purpose inputs/outputs) can sink or source up to ±8 mA, and sink or
source up to ±20 mA (with a relaxed VOL/VOH) except PC13, PC14 and PC15 which can
sink or source up to +/-3mA.
So what I understand is: total current is 150ma, that would be like ~40mah taken for the board and the rest for components.
I/O PINS can drive a RED LED at full power 20ma (max 25ma)
There are other PINS: TTL limited to =+ 8mA. So I usually use PA10 as serial RX1 at 8ma but if I config it as an output I can get 25ma from it.
Is that correct?
Thanks GOD I’ve bought MapleMini for my students ![]()
I think USB hosts e.g. PC’s have to be able to provide 100mA and the peripheral can negotiate for up to 500mA.
http://electronics.stackexchange.com/qu … a-usb-port
But I think you are getting bogged down in the technicalities
If you need to drive a lot of current of any of the outputs, or multiple GPIO pins each with moderate current e.g. 10mA, you should use something like a FET and run the high current side from a separate supply.
at <least>they are in Arduino_STM32-111215-0000 as i’ve reverted.
stephen
<edited>
${DIR}/upload-reset ${dummy_port_fullpath} 750
MD5:
d0e81d1e2b0eb9457a4acb4da44aa688 upload-reset
It’s the same file as upstream: https://github.com/rogerclarkmelbourne/ … load-reset
Thanks both.
https://github.com/rogerclarkmelbourne/ … tools/src/upload-reset
e.g gcc upload_reset.c -o upload_reset
then copy the binary into /tools/linux
I´m trying to burn the bootloader via an FTDI adaper and i get the cannot handle the device error. (BOOT0 to 1, RX->TX, TX->RX)
Downloaded the demo flash tool and set write protection to off even thought it showed all green. (same settings)
Read something about adding a resistor, but do i need to add it if i can read via demo flash tool ?
even try swapping TX and RX.
If it sill wont upload via serial, there is something seriously wrong with the board, as serial doesn’t even need the external clock to be running in order to work
RX->TX, TX->RX like uploading sketches or using flash demo tool, RX->RX TX->TX not working (why would it?).
BOOT0 is High like when i uload sketches or when i can use flash demo tool.
Using PA9/10 now instead of lead out RX/TX still no change.
The only thing that could matter is that i power the board via 5V line, if i power via 3,3V which pin i use VBAT or3.3V ?
I can upload sketches and use flash demo tool, i only have problems burning the bootloader
https://www.dropbox.com/s/v196u3hy60tap … l.jpg?dl=0
https://www.dropbox.com/s/p6rwqfnkaapbr … l.jpg?dl=0
C:\Users\Master\Documents\Arduino\hardware\Arduino_STM32-master\tools\win>stm32f
lash.exe -w ..\..\STM32duino-bootloader\STM32F1\binaries\generic_boot20_pc13.bin
COM_34
stm32flash 0.4
http://stm32flash.googlecode.com/
Using Parser : Raw BINARY
Cannot handle device “COM_34”
Failed to open port: COM_34
Installing the stm32duino bootloader
The bootloader bin needs to be “flashed” onto generic boards as they usually do not contain any form of bootloader.
The simplest method to flash the bootloader onto a generic board is to use a USB to Serial adpator attached to Serial 1 PA9 and PA10, and set Boot0 HIGH.
On Windows. Open a command prompt and CD to the repo install directory, in My Documents\Ardruino\hardware\Arduino_STM32\tools\win (Other OS’s use the same structure below Arduino_STM32).
Then run the exe
stm32flash.exe -w ..\..\STM32duino-bootloader\STM32F1\binaries\generic_boot20_pc13.bin COM_XXXX
Where COM_XX is the windows com port e.g. COM14 of your USB to serial device, If your board has the LED on a different pin, use the bin file that matches your board.
Just tried V0.5 of stmflash, still not working.
DFU is working fine, i dont even need to upload a sketch before listening to serial monitor it´s exaclty like an arduino. (listed as maple mini)
THANKS FOR YOUR HARD WORK !!
If I create a Wiki account for you, do you think you would have time to enter the details for this board into the Wiki ?
That’s what you would think, but the first one I ever tried I was using the adapter shown at about 5:30 into this video and couldn’t figure out why I could not communicate with the board.
Labelling can be confusing.
BTW. I will do a blog post about this, but I bought a USB extension / adaptor cable with a panel mount USB socket on one end and a normal USB plug on the other. As I wanted to put a USB socket on the back panel of a project.
So I cut the USB plug off the cable and wired it up, as it had the normal USB colour coded wires, Red, Black, Green and White.
However… I nearly blew my board up, because the cable was wire with Black = +5V and Red = GND !!!!!!!
You mean me ?
Ofcourse i will help where i can but i wont stay with this board for long (but can test upon request), cause my STM32F103RCBT6 leaflabs Leaf maple mini should be arriving this/next week.I need the DAC in my project and i want a breadboard compatible board for further testing. I also ordered a similar board without jtag (http://www.ebay.de/itm/172113793450?_tr … EBIDX%3AIT) and i´m curious how the RTC works.
Can you link to the board with DAC
Neither the Maple Mini or the board you linked to (which the forum call the Blue Pill akak BP), have DAC.
There are a few boards that have DAC,
I suspect the cheapest board you can find on eBay that has the DAC is probably this V series board
http://www.ebay.de/itm/STM32F103VET6-AR … SwIgNXnEk0
Or this F103RCT board
http://www.ebay.de/itm/ARM-STM32-STM32F … SwiLdV9kCy
But I have this board and it was not good quality.
The F103VET board is much better (but is 3 Euro’s more expensive)
Try searching for posts by @madias, or perhaps PM him (he is in Vienna) (not far from you
As he uses uses MIDI and other synth, so perhaps he can advise
USB STM32F103RCBT6
The seller doesnt say it has DAC, but looking for a datasheet with the chipname does so i´ll just have to wait and see.
http://www.datasheet4u.com/pdf/STM32F103RC-pdf/847306
I hope it is breadboard compatible.
Moreover the RCB mean CB there..
Btw, “clever” sellers at the ebay currently add magic string “ESP32” to their offerings.
I am sure you will get a STM32F103CB device on a Maple mini
You could try sending a question to the vendor, and ask them to confirm that the device is a STM32F103RC series device and not a CB series device.
You may be able to get a full refund without sending it back.
It depends on the vendor. Some seem to give a full refund without you sending the board back, but some vendors do not care even if you give a negative review.
The other option, is to just say you did not receive the board if its not what you expect.
Then you can get a refund for not receiving the board.
But pretending to not receive the board is not ethical, but often the vendors are not ethical ;-(
They get some information from a bigger instance or copy paste infos that seem correct at the first glance.
Its not very expensive but if its not the chip he named in the description i will definately contact him.
For instance i bought an 128*64 oled (http://www.ebay.de/itm/162123795369?_tr … EBIDX%3AIT) and the seller provided a datasheet from a 132*64 solomon systech oled with SSD1305, but in the end i got it working (with some bugs but they could be board related aswell or they are init related) and did not rate neg.
Now i ordered 2 raystar oleds from tme with the right datasheet, hope they have the necessary resistors and so on so i can try to get them work perfectly
BTW, anyone knows what to heed for to know that the display already has resistors/etc. on the board ?
What i am looking for is a breaboard compatible board so futher testing with more devices is easier since i dont have to use Pin->Dupont cable->pin connections.
When everything works as expected i want to print boards at seedstudio or somewhere similar (we did once, but without resistors and chips and it worked fine) anyways so its just for testing phase.


