I’ve successfully programmed an Iteadmaple using the stm32 distro under 1.6.1, but this is the first time I’ve tried to program one of these clone minis.
The mini clone’s LED pulses at a steady 2Hz, if I press “reset”, it flashes quickly 6(?) times, but pressing and holding the 2nd button doesn’t seem to put it into perpetual bootloader mode.
Any advice appreciated. Here’s the ebay listing of the unit I bought for reference:
http://www.ebay.com/itm/311248450407
Edit: The logo that is obscured in the photo reads “BTE14-07”. According to the listing specs it should be a RCBT6 device (chip read STM32F103CBT6).
– On bootloader mode (light flashing) it’s a DFU device. It’s not enumerated on Arduino IDE.
– On running mode it behaves like Arduino, as a serial device (I use Linux and it’s enumerated as ttyACM device instead ttyS device, but both are more-or-less the same).
BUT (and it’s a very big BUT) it only shows when you start serial device on sketch. It’s so simple as adding Serial.begin(9600) at the beginning of the setup function.
OK, thanks. I see that when I select USB->Flash programming option (instead of the “keep bootloader” or “lost bootloader!” options), it does find the device, programs it, and the device subsequently enumerates as a serial device.
What are the differences between the three programming modes? In particular, what bootloader is it looking for (which evidently my device doesn’t have)?
Also, I’m not seeing a “bootloader version” in the menu.
OK, thanks. I see that when I select USB->Flash programming option (instead of the “keep bootloader” or “lost bootloader!” options), it does find the device, program it, and the device subsequently enumerates as a serial device.
What are the differences between the three programming modes? In particular, what bootloader is it looking for (which evidently my device doesn’t have)?
Is quite complicated and changes between versions (the one of the screenshot is not very updated, as it’s not the computer I use to program microcontrollers).
It’s quite complicated (Roger, maybe there should be some cleaning, rearranging and better titles), but different options are for different boards and configurations; there’re a LOT of STM32 boards out there….
There has been cleaning and changes… just a compromise between necessary “short descriptions” and many board, bootloader options. I’m sure Roger would take suggestions for changes and put it to a vote in his usual democratic style: but to simply imply changing without offering suggestions is IMO just noise 
The bootloading process has been explained many times previously! I am not going to repeat what can be found by searching this forum.
https://www.google.com/search?q=bootloa … 1&ie=UTF-8
Ray
Also, I’m not seeing a “bootloader version” in the menu.
As nobody is using the original leaflabs boards e.g prior to rev , and we only upload to flash.
People dont seem to bother to read the wiki on the repo. The installation details are quite clear now for all platforms.
But I agree, that once the Repo has been installed, there is a gap in documentation, in terms of what board to select and the upload menu options.
I will see what i can do in terms of doing some documentation, and perhaps a video
I have a generic STM32F103C8T6 development board and have had no problems uploading to it using serial once I worked out to ignore the TX and RX pins and use pins PA09 and PA10 instead (thank you Roger Clark, you saved a few remaining hairs on my head).
I also have a Maple Mini clone which I would prefer because of its slim form factor and would be easier to fit into some of my existing projects that use Arduino Nano v3 boards. I had, until tonight, no success getting it to upload. I read every scrap of info on the git and the forum and I have been following Roger Clark and Ray Burnette’s blogs, etc for months. My board only uploaded once and that was it. DFU can find it, the USB serial port works a treat (Windows 7) but I fluked it the first time and couldn’t time it properly after that. I have tried this with both Arduino (1.0.6, 1.5.1, 1.6.0, 1.6.4, 1.6.5R2) and MapleIDE with consistent failure.
Hoping my accidental workaround might help others with the same issues (Currently using Arduino 1.6.5R2 and Arduino_STM32 from last week…).
I have a Prolific Serial adaptor connected to Serial1 (RX1-D25. TX1-D26).
1. I select this second, non-USB port as the serial port in the Arduino IDE.
2. Then I put the Maple board into bootloader (DFU mode) buy pressing the reset button quickly followed by holding the other button for about 2 seconds until I get the consistent flashing light.
3. I upload my sketch and it automatically finds the DFU and uploads without any of the USB port reset issues and associated timing problems.
4. If I want to monitor the output of the Serial (USB) i just change back to that before running the Serial Monitor otherwise I send my debug output to Serial1 (through my ttl-USB adaptor).
Sounds like a no-brainer but I was about to relegate the Mini to the “maybe look at it again some day if I am really that bored” bin…
I also have a Maple Mini clone which I would prefer because of its slim form factor and would be easier to fit into some of my existing projects that use Arduino Nano v3 boards. I had, until tonight, no success getting it to upload. I read every scrap of info on the git and the forum and I have been following Roger Clark and Ray Burnette’s blogs, etc for months. My board only uploaded once and that was it. DFU can find it, the USB serial port works a treat (Windows 7) but I fluked it the first time and couldn’t time it properly after that. I have tried this with both Arduino (1.0.6, 1.5.1, 1.6.0, 1.6.4, 1.6.5R2) and MapleIDE with consistent failure.
Can you confirm.
1. If you select the Maple com port that the board is not reset by the IDE prior to upload?
2. If you turn on Verbose in the IDE prefs, do you get any messages?
It sounds like the java utility that is supposed to send the reset sequence to the board is crashing while its trying to reset the board via serial usb.
Unfortunately, I don’t have the source for the Reset utility on Windows.
I had to write a separate “upload-reset” utility, for OSX and Linux, but i suspect, i can’t compile it for Windows, as I think the way Windows interacts with the DTR and CTS lines is different. (Though i will take a look, to see if I can compile it using MinGW )
Do you have any machines running Linux or OSX you could try , to see if the reset works on those platforms.
If you cant see any errors in the reset sequence, you could try putting the new bootloader on the Maple mini, but it doesn’t really sound like its a bootloader issue
This is a really cheap Chinese clone but the only rework they claim has been done is in the power supply area where the vin has a couple of Zener diodes in series with the input, making it very practical for use hooked directly to a 18650 li-ion battery (as I do in most of my projects).
Workaround is great. I have rewritten my sketches to use Serial1 for debugging output so I don’t even need to switch back. I just use the USB port as a power source and DFU uploader. It is so quick this way (except I get sore fingers doing the button thing too often to put it into perpetual bootloader mode).
I feel like such a dummy. I have been wanting to upgrade the bootloader for months thinking that it might fix this problem but had no idea how. There is a sketch? Damn. Early onset dementia I am sure (started when I was a teenager and has only gotten worse – got into Mensa at 12 but am flat out adding two numbers now…). Where is this sketchy bootloader thingy to be found that I might make use of him? Thanks again. Am loving your work (currently disecting and using parts of I2C_SPI_SDcard_GLCD because I have not had the joy that Naguissa had with SD cards on the STM32s).
Roger,
I wouldn’t lose any sleep over it. I just thought if there was someone else out there who ran into this problem it would help them out. In fact I have now rewritten my sketches for the Maple Mini as described above. But if you are interested here goes…
DFU has always seen it as [1EAF:0004] until I got it into my head to manually reinstall it forcing the desctiptor to be [1EAF:0003] so that I could use DFUDemo to read the thing, etc.
Trouble is that I did that before understanding and realising that the multiple driver model that Maple used (not realising that 0003 was for the SerialPort emulation and 0004 was for DFU driver) enables the one device to look like two and work semi-concurrently under Windows.
As a result I think I have trashed my system settings through this and couldn’t be bothered manually cleaning the registry and starting over. I am sure there is nothing wrong with your code. I started playing with these (and the ESP8266) a while back before there was lots of info out there and because I am using most of these bits in a (boutique) commercial environment (covering ears to block all the gasps because this is supposed to be for hobbyists and not serious professional stuff) I had to move on to things that were more mainstream in the interests of speed of development and production.
I have been using DUEs where the Nano and UNOs are not powerful enough (usually run out of memory, timer lines and interrupts, etc on the smaller guys) but they are huge which is why I decided against the MEGA2560 in the first place.
I saw the Maple Mini and thought “That is only slightly bigger than my Nano v3s and has so much more resources I could use without reworking my existing boards and equipment form-factors too much” and went for it. That is why I appreciate what you guys are doing here because it has brought it back into practical realms of possibility for me. I just can’t justify spending too much time on it though because I can always use a second $2.50 AUD Nano v3 as a slave on a read-only serial line to solve my problems in that way (which I do in some of my equipment).
Again I would like to say Thankyou to yourself and those in this community for your efforts as it has opened up a whole new world of possibility for me (and others I am sure).
Cheers.
Oops. In my incessant raving I neglected to properly answer your question.
OSX? From where does this dark muttering spring. Avoid the poison Apple at all costs…
Linux. Have one production machine at present with several VMs running under Windows (very well I should add for the Windows haters out there) under Oracle VirtualBox VMs (I do use Hyper-V on some of my servers and on my Windows 8.x machines but my main dev beast (decommissioned architectural CAD laptop of my daughter’s – ASUS Lamborghini VX7 – i7 quad core, 16G RAM, Dual HDDs, BlueRay combo drive (DVD burner), nVidia GeForce GTX graphics, Full-HD 3D screen) is running Windows 7 and the Oracle lets me redirect USB ports.
I have installed Arduino 1.6.5R2 on one of my Open SUSE VMs but have had some trouble with installing your libraries, etc. But I haven’t taken the time to read the documentation or to do it properly so it’s fair enough and to be expected (have only spent about half an hour trying on linux so far as Windows works fine for me).
Oops, more incessant raving. This is why I usually watch without contributing…
Cheers,
Garth.
There is now a utility to reset the maple mini via serial usb on both OSX and Linux.
Osx and Linux dfu-util binaries are now part of the repo
There is also a fix, mainly for OSX, for a bug in stm32flash not working with some USB to serial adaptors.
There is also an improved linux install script for udev rules etc (tools/linux/install.sh )
I also did a new video about first steps with Maple mini , which follows on from my other 2 video tutorials
Various pages in the wiki including the installation stuff have been uodated.
).
Sadly I’ve really problems with my macbook and the mini since a few weeks. Even the touchpad stucks for a few seconds sometimes while uploading. It’s interesting: After a cold reset of the mac everything is running fine then some strange things (hangs) and after that I’ve to set the mini every time into perpetual bootloader mode or press “upload” 6-7 times. Interesting part: The “reset” for the mini works every time, so this isn’t a problem. I think my problem is more with the mac hardware and/or kexts (maybe the last update broken it? ) But nothing to bother the forum, because I’m the only one with this “symptoms”. One thing I could try out is a usb port expander.
Edit: It’s nearly impossible that this problems was caused by a repo update, because I’ve always more then one active and even the all time working older repo show this behavior .
i had to add a delay in the upload-reset utility, as it takes the mac at least half a second to re enumerate the usb.
The delay value is passed by the script, so you could try making it longer or shorter.
I found the lower limit on my hackintosh was about 0.5 secs and the upper limit before dfu-util times out is a bit over 1 sec.
A better fix would be to modify dfu-util so that it scans for dfu devices for a defined amount of time.
The PC version of dfu util seems to scan for longer, but i dont have the sources for the version of dfu that we use on the PC, and i think the last time i tried to compile the latest version of dfu-util as the PC exe, it didnt work ( i cant remember why)
With OSX, Apples track record with recent releases is not good.
Could you try installing a fresh copy of OSX from your original install disk?
But i know how long that takes 
and of course you would need to back up first.
I normally end up buying a new HD if i have to do this, but its a costly option.
I think you mean this value:
${DIR}/upload-reset ${dummy_port_fullpath} 750 /* Reports wrong DFU version in DFU descriptor */
if (vendor == VENDOR_LEAFLABS &&
product == PRODUCT_MAPLE3 &&
bcdDevice == 0x0200)
quirks |= QUIRK_FORCE_DFU11;On OSX and Linux, I thought we were just using the standard dfu-util code without any fixes for Maple mini, but perhaps they added a hack for maple mini into the master source of dfu-util
The time it waits for upload, (as a dfu device) is now less than it was in the original version.
I didnt make this change, I think it could have been in the repo I used as the basis for the code ie jonathanolfson’s repo
We may need to extend this a bit, to give some systems a larger window of dfu availability
<…>
I have been wanting to upgrade the bootloader for months thinking that it might fix this problem but had no idea how. There is a sketch?
The time it waits for upload, (as a dfu device) is now less than it was in the original version.
I didnt make this change, I think it could have been in the repo I used as the basis for the code ie jonathanolfson’s repo
We may need to extend this a bit, to give some systems a larger window of dfu availability
Any idea of what value we should use? i.e how long it should wait? Perhaps i should look in the leaflabs maple-booloader repo and see how long it originally was.
Edit. I looked at the value of BOOTLOADER_WAIT in maple-bootloader and in our bootloader and both values are set at 6.
Which equates to 6 flashes of the LED.
So. I think we need to have a definite need / problem on some platform, before we change this, changing this will decrease the startup time i.e when development has finished and the board is being deployed standalone.
At the moment, I like the way that you don’t need to wait ages for the bootloader to start running the sketch.
If we do have issues on some platforms with uploading, I think we’d be better of trying to work out why dfu was having issues. e.g. is the timeout inside DFU too short.
I know Matthias has looked at some of the timeout values in dfu-util, but I’ve not been able to look at the source yet, because the source was missing from the repo because my repo just linked through to Gitorous, and that site is now offline. (see my posting in General Discussion).
Anyway, now I’ve added the dfu util sources back into the repo, I should be able to investigate the timeout stuff, at least on Linux, because I think I managed to get it to build Ok on Linux (I’ve not installed all the necessary build tools on OSX yet)
Any idea of what value we should use? i.e how long it should wait? Perhaps i should look in the leaflabs maple-booloader repo and see how long it originally was.
Edit. I looked at the value of BOOTLOADER_WAIT in maple-bootloader and in our bootloader and both values are set at 6.
Which equates to 6 flashes of the LED.
So. I think we need to have a definite need / problem on some platform, before we change this, changing this will decrease the startup time i.e when development has finished and the board is being deployed standalone.
At the moment, I like the way that you don’t need to wait ages for the bootloader to start running the sketch.
If we do have issues on some platforms with uploading, I think we’d be better of trying to work out why dfu was having issues. e.g. is the timeout inside DFU too short.
I know Matthias has looked at some of the timeout values in dfu-util, but I’ve not been able to look at the source yet, because the source was missing from the repo because my repo just linked through to Gitorous, and that site is now offline. (see my posting in General Discussion).
Anyway, now I’ve added the dfu util sources back into the repo, I should be able to investigate the timeout stuff, at least on Linux, because I think I managed to get it to build Ok on Linux (I’ve not installed all the necessary build tools on OSX yet)
Ah, ok. So its a windows enumeration speed issue.
I have some older machines (laptops), that have around 1hgz processors, i will see if they have this issue
I agree 9 flashes would be ok if it helps users on slower machines
Ah, ok. So its a windows enumeration speed issue.
I have some older machines (laptops), that have around 1hgz processors, i will see if they have this issue
I agree 9 flashes would be ok if it helps users on slower machines
I run all kind of stuff on it, so is a bit bloated, which may affect it someway, but still is an i3 with 6GB.
May be just a thing with my laptop, don’t know, but as I said is not a big issue. Normally I just put the boards in perpetual mode, but I may just compile a bootloader with a bigger delay.
, and have not noticed any problems.
I have some old laptops (Probably dating back to about the year 2000), but I’m not sure what OS’s are installed on them, but I will see if I can install the latest IDE on the oldest machine, which I think is a 1Ghz (or less) machine with not much ram by todays standards !
I’ve installed 1.6.5.r2 on my old XP (which dates to around 2003 I think), and the USB works fine. I could be that XML is actually faster than Windows 7, but it definately doesnt have any problems
Perhaps its just something on your machine. So perhaps we should leave the timeout at 6 (flashes) in the bootloader
Thanks
Roger
