Clone Maple Mini

I’m trying to upload the bootloader on a plate based on maple mini clone. Here is the schematic: http://uploadpie.com/2diXq

I am using PL2303, the boot0 pin is 1 with a resistor pulled up and boot1 is at GND. I have already put other values in the resistor as 10k, 4k7 and does not upload the bootloader.

Any suggestion?

Pull Boot0 with 1k up. Double check serial wiring – rx and tx and gnd pins. If you got a spare led, make a small probe ( –tip—4k7—|>|—-gnd) and look at the serial pins what is going on there..

I changed into a 1k resistor and still did not work. I tried with the flash loader demonstrator stm software and appears the error: No response from the target, the boot loader can not be started.

Which pins do you use for RX and TX??

PA9 and PA10

Try keeping But pressed also after the board reset.
What worked for me (note I have a USB2Serial adapter which features a reset button):
– press (and keep pressed But on MM)
– press reset on the USB2Serial
– run Usart upload while keeping But pressed

best, E.

Pull boot1 low, it us currently floating and may cause problems

Try Tx and RX the other way around. Some USB to serial adaptors have them labelled incorrectly.

Double check what Com port you selected in the Flash loader demonstrator, some PCs show dummy COM ports e.g Com1 which is not you usb to serial adaptor, check in the device manager to get the com port number

Hi guys,
I have to reopen this thread, I have not used my Baite maple mini (MM) for couple of months, and now I cannot flash it anymore.
The sw I flashed last time runs well, but it does not uses the USB serial, only serial 1.
Adruino 1.6.9. gives the following message:
Sketch uses 51,056 bytes (41%) of program storage space. Maximum is 122,880 bytes.
Global variables use 9,072 bytes of dynamic memory.
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!
Cannot set alternate interface: usb_set_altinterface: could not set alt interface 0/2: win error: No more data is available.

Opening USB Device 0x1eaf:0x0003...

Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="UNDEFINED"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Invalid library found in C:\Users\Zo\Documents\Arduino\libraries\temp: C:\Users\Zo\Documents\Arduino\libraries\temp

Steve

Try pulling Boot1 low and upload a sketch using USB to Serial, ( or try using STM’s own flash loader tool)

I think on the MM Boot1 is floating and occasionally it floats high when uploading via serial, which will cause the binary to go into RAM not flash.

If you pull Boot1 high and Boot1 low and still cant communicate via USB serial, either the MM is dead or the USB serial is defective or not connected correctly.

Note. If USB to Serial works to upload, but the code does not run, its possible the 8 MHz clock is not working, as USB serial uploads do not use the external clock(s) ( I presume they use the internal HSI clock)

Roger, thanks for the hint with BOOT1, I checked the schematic, it is floating indeed, I will try to pull it to GND with 10k resistor to avoid a short if PB2 is used as output and set to high in the currently running on-board SW.
What bothers me is that it worked before in the same constellation.
The USB->serial adapter must be OK since it works for the blue pill, the ST flash demonstrator tool can communicate/read out data.

Is it normal that the USB COM port doesn’t work on-chip if not used in the sketch? I only used Serial 1 for debug outputs.
I cannot otherwise explain why the alternate interface is not found after the DFU port is recognized/identified by the maple loader:
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]…
Found it!
Cannot set alternate interface: usb_set_altinterface: could not set alt interface 0/2: win error: No more data is available.

Steve

That doesnt sound good.

Even if boot1 is floating it should at least make contact.

Double check boot0 is high

I don’t suppose you have a STLink, as thats the best option, You could program the BluePill as a BlackMagic probe (or even a STLink if you can find somewhere to download the STLink binary from – as its not publically released by STM)

BOOT0 is set to “1” for sure, because I cannot see the LED blinking after reset.
I also tried the upload over USB->serial by keeping the BOOT0 button pressed during trying to flash. No success.
So I assume BOOT1 is here the issue, because if it set to “1” at boot phase, the system tries to boot from SRAM instead of system memory. I will check this evening what happens when is tied low.

But the issue with not working upload over USB when USB serial is not used by the sketch is reproducible. Just try to open a new minimal sketch where you define at the top of the sketch: #define Serial Serial1. You won’t be able to upload new SW over USB anymore…unless you flash the bootloader again (or upload over serial 1 with BOOT1 set to low at reset ? – did not try this yet).

BOOT1 tied to low, BOOT0 tied to high and voila…it worked like a charm:

stm32flash 0.4

http://stm32flash.googlecode.com/

Using Parser : Raw BINARY
Interface serial_w32: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (sector size: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x08001b7c (100.00%) Done.

Steve

OK. I am sure I have posted about the Boot1 floating issue before. But it doesnt do any harm to have another thread about it.

Though its odd it will not communicate at all with Boot1 floating. I thought it would connect and upload, but the upload is supposed to go into RAM, which is not much use to us.

I think, when the BOOT1 is high at reset, the CPU jumps into nirvana (SRAM), so that it cannot execute the upload code if SRAM contains trash. Or am I missing something?

Steve

I dont think boot1 comes into play unless boot0 is high, otherwise the booting of the Maple mini would be unreliable, as boot1 is floating.

IMHO this is a design mistake by Leaflabs and they should have added a pulldown e.g. perhap 47k on boot1

Could upload the bootloader, the problem was solder paste, dirt, but did not understand the reason que solder paste hinders the operation. Simply used the product to clean board, and ran upload the bootloader. The problem after uploading the bootloader, the board is not recognized in the USB, it is only the LED flashing continuously. Any suggestion?

xxLogamxx wrote:Could upload the bootloader, the problem was solder paste, dirt, but did not understand the reason que solder paste hinders the operation. Simply used the product to clean board, and ran upload the bootloader. The problem after uploading the bootloader, the board is not recognized in the USB, it is only the LED flashing continuously. Any suggestion?

I have already installed the windows drivers as FAQ, but does not work. I looked in the mini maple site:

“The first team you upload the program after installing the new bootloader, there is the need to select the serial port in the IDE [1]. Perform this first upload with the serial port selected. The IDE will emit a warning about not finding a serial port, but the will still succeed upload. in subsequent uploads, select the serial port as you would Normally. “

I’ve tried using maple IDE, but without success. In Linux the following error appears using the Arduino IDE:
dfu-util 0.8

dfu-util: Invalid DFU suffix signature
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
dfu-util: A valid DFU suffix will be required in the future dfu-util release !!!
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is free software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]

dfu-util: In DFU capable USB device available

On Linux using the Maple IDE:

Loading via dfu-util
Resetting to bootloader via DTR pulse

Reset USB Serial Failed! Did you select the right serial serial port?
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming …

Searching for DFU device [1EAF: 0003] …
Error!

Could not find the DFU device: [1EAF: 0003]

Any suggestion?

As researched forum, tested with older gcc 4.8.5 and still does not work. By uploading the bootloader it is without error, but the output of dmesg:
[8814.584290] usb 3-3: new full-speed USB device number 113 using OHCI-pci
[8814.992261] usb 3-3: device not accepting address 113, error -62
[8814.992316] usb usb3-port3: Unable to enumerate USB device

Already I changed the cable and also check out the USB connector. Any suggestion?

I am not sure what the issue is, but I suspect you might have more success programming with one of the ST-Link V2 clones.

...
kern.log.2.gz:Sep 29 15:18:47 ahull-T430 kernel: [14845.450625] usb 1-1.5.6: new full-speed USB device number 14 using ehci-pci
kern.log.2.gz:Sep 29 15:18:47 ahull-T430 kernel: [14845.856457] usb 1-1.5.6: device not accepting address 14, error -32
kern.log.2.gz:Sep 29 15:18:47 ahull-T430 kernel: [14845.928413] usb 1-1.5.6: new full-speed USB device number 15 using ehci-pci
...


Try to full erase the chip and reprogram the bootloader only. The enumeration failure is caused in 95% of cases by cable/connector failure or some kind of short circuit in usb lines. Is your MCU OK? Try to program the MCU with serial port and test the behavior of CPU, make some IO operations in USB pins (with USB not enabled). It is possible to have faulty MCU or USB peripheral.

ahull wrote:I am not sure what the issue is, but I suspect you might have more success programming with one of the ST-Link V2 clones.

...
kern.log.2.gz:Sep 29 15:18:47 ahull-T430 kernel: [14845.450625] usb 1-1.5.6: new full-speed USB device number 14 using ehci-pci
kern.log.2.gz:Sep 29 15:18:47 ahull-T430 kernel: [14845.856457] usb 1-1.5.6: device not accepting address 14, error -32
kern.log.2.gz:Sep 29 15:18:47 ahull-T430 kernel: [14845.928413] usb 1-1.5.6: new full-speed USB device number 15 using ehci-pci
...


Slammer wrote:Try to full erase the chip and reprogram the bootloader only. The enumeration failure is caused in 95% of cases by cable/connector failure or some kind of short circuit in usb lines. Is your MCU OK? Try to program the MCU with serial port and test the behavior of CPU, make some IO operations in USB pins (with USB not enabled). It is possible to have faulty MCU or USB peripheral.

I don’t think you can simply put a voltmeter on the USB pins (PA11 and PA12) as they contain USB data and will not simply be a DC voltage.

Even if you look at them on a scope, I’m not sure if you will see anything useful, as the host may be constantly signalling to the peripheral.

You could verify you have not fried the GPIO on those pins, simply by uploading via USB to serial and powering from the USB to serial converter and NOT connecting the Maple Mini USB connector to the PC

Run a sketch which toggles GPIO on PA11 and PA12.

Also, if you upload via USB to Serial, (select that option in the IDE), it does not enable USB as it presumes you have connected the USB Serial to PA9 and PA10 in order to upload and hence want to do Serial.print via the same connection (PA9 and PA10)

So you are free to use PA11 and PA12

RogerClark wrote:I don’t think you can simply put a voltmeter on the USB pins (PA11 and PA12) as they contain USB data and will not simply be a DC voltage.

Even if you look at them on a scope, I’m not sure if you will see anything useful, as the host may be constantly signalling to the peripheral.

You could verify you have not fried the GPIO on those pins, simply by uploading via USB to serial and powering from the USB to serial converter and NOT connecting the Maple Mini USB connector to the PC

Run a sketch which toggles GPIO on PA11 and PA12.

Also, if you upload via USB to Serial, (select that option in the IDE), it does not enable USB as it presumes you have connected the USB Serial to PA9 and PA10 in order to upload and hence want to do Serial.print via the same connection (PA9 and PA10)

So you are free to use PA11 and PA12

xxLogamxx wrote:
I had already taken the test as you said. I uploaded and used powered by PL2303. I can conclude that the pins (PA11 and PA12) burned?