And I’m confused as heck on how to get it working properly!
My primary goal here is to get it working with Arduino in Windows 10, but I’m happy to set up in other configurations to get it working properly (Linux, other upload / firmware software).
When I first got it it was doing the quick 6x flashing, and then slow, I went through all the steps to update my software and download the Arduino package as per: https://github.com/rogerclarkmelbourne/ … stallation
Before I installed the driver properly the device was “Maple 003”, now I get the “Maple DFU” under libusb-win32.
The problem was no matter in what order I pressed the “but=32′ and reset buttons, the only mode I could get it into was the serial load mode and I could not get the sketch onto the device.
After many attempts to load on a blink sketch with no useful outcome, I got out my USB serial adaptor and decided to load on the bootloader 2.0 bin. (http://blog.lincomatic.com/?p=1771)
Then no LED, device is still working, and I can reload the firmware, reset device, load on sketches from the Arduino IDE, but nothing else happens, no pins going high or low, nothing. To load on firmware I still need to hold but while pressing reset to get it in the right mode, so that’s not stuck.
This is the blink program I am now attempting to use:
// the setup function runs once when you press reset or power the board
void setup() {
Serial.begin(9600);
Serial.println("Hello world!");
// initialize digital pin PB1 as an output.
pinMode(PB1, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(PB1, HIGH);
delay(300);
digitalWrite(PB1, LOW);
Serial.println("Loop");
delay(2000);
}
I presume you selected Maple Mini from the boards menu ? and selected “Original bootloader” from the menu below ?
When you upload the sketch, you should see a flashing LED on the board
After upload is complete, you should see the USB device change from Maple DFU to Maple Serial
One other potential problem is connection via a USB hub, or on a USB 3 port, Try another usb port on your PC, often some are USB 1, or USB 2 and some are USB 3
When I upload a sketch:
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=248
Starting download: [##################################################] finished!
error resetting after download: usb_reset: could not reset device, win error: The system cannot find the file specified.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
It looks like it is uploading
Does the led flash as expected ? 300ms On then 2 secs Off
Could just be a dodgy board or MCU.
But it’s possible that the USB on your PC is not detecting that the board has switched to being a serial.USB device.
However this does not explain why the led is not flashing the blink part of the sketch
I can’t test your sketch at the moment. But I will try to test it tomorrow if no.one else has been able to test it
Btw. Can you post the verbose compile output. Just in case it’s some sort of GCC version issue.
Compile with verbose on didn’t show any compile warnings or errors, lots of white lines and the one orange line because I’m using the 1.6.9 IDE.
Here is the verbose on upload:
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=248
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
error resetting after download: usb_reset: could not reset device, win error: The system cannot find the file specified.
Resetting USB to switch back to runtime mode
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=248
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Your maple mini device is being programmed.
You should never select bootloader 2.0 in the IDE unless you have updated the bootloader. To do so is guanarteed to fail.
After many attempts to load on a blink sketch with no useful outcome, I got out my USB serial adaptor and decided to load on the bootloader 2.0 bin.
If the procedure was successful, then you must select bootloader 2.0 …. but are you certain your attempt was successful?
You are on Windows, did you install the Windows drivers?
You simply must stop using a shotgun to fix your problem… be methodical.
1) you should start with reinstalling the Windows USB driver.
2) load the blink&count sketch using bootloader 2.0 option
3) does device manager enumerate?
4) if no, try downloading the sketch using the original bootloader option
5) does device manager enumerate?
Report back.
And…
Always, always, always buy 2x of anyhing cheap so you can use the second one should the first become mired in tge Twilight Zone. The second unit is a diagnostic tool to help issolate hardware from software issues.
Ray
* Unpacked board, put pins in breaboard, soldered on headers
* Plugged into windows, saw "Maple 003" device, and the correct fast flash and slow flash order
* Found instructions for loading stm32arduino, followed to the letter
* Made sure I uninstalled and removed the device before the device driver step
* Plugged the device back in, got "Maple DFU" straight away under the libusb-win32 category in the device manager in windows
* Loaded blink sketch, compiled, then uploaded
* The loader failed to find device, found instructions for pressing buttons in a particular order to get device into loading mode, nothing worked
* Got out my serial USB device and looked for instructions to load sketch for serial. Nothing, attempted a few settings, found nothing that worked to use serial to upload
* Decided only now to get bootloader 2.0, followed instructions to use the windows exe
* Firmware uploaded successfully, now no LED
* Double checked that I had the correct firmware
* Got out multimeter and made sure pin 19 on the stm32f103 was connected to the LED in case I needed a different firmware, all good
* Checked a few other pins to make sure the circuit diagram was the correct one
* Happy with the results I decided to go back to USB and attempt to upload the sketch using bootloader 2.0
* Uploaded OK as per messages above
* Still no LED
* Hooked up multimeter to check voltage while device was powered up, no voltage changes on LED
* Wrote another sketch turning on and off various pins with delays of 300ms or longer for LEDs to be on, hooked up abut 7 LEDs to various pins
* Uploaded sketch, still nothing
* Took all that code out and decided to try serial port, couldn't find a lot of example code for output via serial port, so used Arduino examples
* Uploaded, disconnected, hooked up USB to a Sony branded USB powerpack and hooked the serial up to PC via USB, still nothing
* Went back to firmware, re-downloaded the firmware, uploaded using the python STM32 loader, verified successful
* Uploaded the serial debug and the original blink sketches again using both original and bootloader 2.0 settings
* Also re-wrote firmware in case using original setting overwrote something
* Waited a day, got some sleep
* Tried various combinations of the above with no success, also worth nothing that I re-installed the windows driver and now I have two MapleDFU drivers in windows
* Posted here
https://github.com/rogerclarkmelbourne/ … stallation
At this point, I think I would check over the hardware. I have ordered 2 boards from eBay, but one was defected and I had to reflow to correct it. Both eBay boards were “repaired” as there was flux on the STM32F103 uC.
The manufacturer of the Maple Mini clone has a store on AliExpress and out of 30 boards purchased, I have 30 working boards with no signs of any rework.
http://www.aliexpress.com/store/213957
But, your board appears to have worked initially. I always run bootloader 2.0 but I flash the bootloader from a sketch rather than using the chip serial feature.
You probably know this, but the bootloader cannot enumerate serial comms, just DFU. USB serial is enumerated only when a sketch is successfully loaded. So, when you state,
* The loader failed to find device, found instructions for pressing buttons in a particular order to get device into loading mode, nothing worked then I become very confused.
Ray
http://www.stm32duino.com/viewtopic.php?f=16&t=1103
Maybe it’s fixed, the topic is not clear about that.
The only issue I am having is that the sketch only seems to execute if it is the first sketch uploaded after a fresh bootloader, loading a second sketch (overwriting?) uploads OK, but neither the old or new sketch executes. I don’t mind writing a new bootloader each time for now, it’s only slowing down rapid development.
I still don’t see a Maple Serial device, but I’ll blame Windows for that, might be time to rebuild a computer I have here with Linux.
Use zadig to install the serial driver..
Very strange
Its crazy that you need to upload a new bootloader each time.
I tested the bootloader that is in the repo on my Maple mini and it worked fine.
One other trick I use, if there are USB issues, is to disconnect the USB completely, then press Upload
When the IDE has finished compiling… Plug in the USB and the board should run the bootloader, which is then recongnised by DFU Util, and it uploads straight away
(This still doesnt solve the problem you are having with the Serial USB)
I really wonder if you have a defective board, and it is missing some components etc, as it sounds like it is not able to reset the USB at all.
PS. I suppose you could try the generic stm32f103c board type, as this is the same as the Maple mini, except it uses a different method to reset the USB. This doesnt normally work for Serial USB on the Maple mini, but if your board is different, its worth a try
PS. Can you photo your board and upload to the forum.
Its likely your Maple Mini may be a factor reject that has been reworked, but not re-worked enough for it to function correctly
I have also tried a few cables, all with the same outcome.
I have a limited understanding of what happens when I upload a sketch and how it is executed (like, I understand how the hardware works in most microcontrollers, and that there is a memory map and the bootloader exists in a part of the flash, probably the start). My only suspicion would be if there is some fault in the flash on this board and writing new blocks might be clobbering something it shouldn’t, because I can’t see how a USB fault could cause a block to be written in a weird place. Maybe part of the loader code is being overwritten, which doesn’t hurt the first time, but there after it’s gone. But I’m only making wild guesses.
I took some photos with flash and high contrast so any defects should be more obvious:
https://goo.gl/photos/qgasdSQZEvW9GRNf6
https://goo.gl/photos/SE3r1HXdQHdCgw1Q9
Second one is a little fuzzy, couldn’t get focus, I can have have another go if you want.
I’m happy to keep chasing this down for the fun of it until I get a couple of replacements, trying different things; but don’t expend too much effort. When I get some more (might even get something a little more official or less ‘cheap’ as well), I’ll report my findings good or bad in this thread.
The bootloader and the sketches are standalone
The bootloader is loaded into the base of the flash, (which is some strange location like 0x800000) (I think this is also mapped to 0x0000000 but most places refer to 0x800000 as the start of flash)
When the MCU starts it runs the bootloader
The bootloader code implements the USB DFU device, so that when you plug the board in, it will initially appear as the DFU device under libusb as Maple DFU
The bootloader waits about 1 second as the DFU device, but if the IDE doesn’t connect and start uploading in this time, the bootloader checks if there is a valid sketch at 0x8005000 and if there is, the bootloader just jumps to that address and the sketch starts to run
The Sketch has the USB serial code in it. So what is supposed to happen is that the PC notices that there is a different USB device (Maple Serial) when the sketch runs.
But to tell the PC that something has changed on the USB bus, the Maple mini uses the 2 transistors under the board, (under the USB connector) to toggle the USB DM line – in accordance with the USB spec related to device connection
Normally the PC will notice that the usb device has changed, and you will see the Maple Serial device (which is allocated a COM port)
In the IDE, when you select that COM port. – When you press upload, the IDE compiles, and then calls the Maple_upload.jar file
The jar file sends a magic sequence of chars via the COM port to the board (and toggled DTR)
The sketch code constantly listens for the magic sequence, and when that sequence is received, the sketch forces a reboot of the MCU, so that it runs the bootloader again, which appears as the DFU device (after first resetting the USB bus), so that dfu_util (which is called my maple_upload.jar), can send the sketch to the board
But, precisely why this sequence is not happening for you, I really don’t know
It is possible for the sketch to over write the bootloader, but not just running normal code, you’d need to use the EEPROM library to specifically erase the pages of flash for the bootloader
(Note the new bootloader is smaller than the original one that comes pre-flashed on the boards from China. So the start address of the sketch for the old bootloader is 0x8005000 where as if the new bootloader is installed, the sketch is flashed into 0x8002000)
However these addresses are hard coded into the bootloader, so I don’t think its possible to overwrite the bootloader with sketch code
(Well, I guess it may be possible, but I’ve never seen it happen, and I didnt know it was possible)
I also have problems with USB / DFU on Win 10 machine. Sometimes the IDE can reset the board (generic C8) after uploading the new sw, sometimes not.
I use an old(er?) version of bootloader, since several months in action (don’t know the exact release date, check out long time).
My solution to not recognizing it as serial:
– go to device manager and disable the Maple DFU device, then re-enable it again. This should trigger a new HW scanning of the device manager and then it should interpret it as serial device, allocating a COM port to it, if the driver was correctly installed. You should then select the respective COM port as interface in the Arduino IDE!
So I think w10 sucks, or the bootloader is not quite adapted to w10 USB driver, or vice versa.
<…>
So I think w10 sucks, or the bootloader is not quite adapted to w10 USB driver, or vice versa.
<…>
I use an old(er?) version of bootloader, since several months in action (don’t know the exact release date, check out long time).
<…>
– Previous version is working on the Maple Mini Clones, the Baite’s and the cloned Baite’s
– New version working on the “real” Baite boards, not on the clone Baite
The hardware on the clones is not up to spec to work the the changed timing in the new bootloader ?
– Previous version is working on the Maple Mini Clones, the Baite’s and the cloned Baite’s
– New version working on the “real” Baite boards, not on the clone Baite
The hardware on the clones is not up to spec to work the the changed timing in the new bootloader ?
Still the previous version of the bootloader worked on the same (bad…) board. So it has to be a combination of two things, the board hardware and the (changed) bootloader.
<…>
So it has to be a combination of two things, the board hardware and the (changed) bootloader.
i looked at one of mine, wiped that area, no solder anything in that area or anything without solder resist.
srp
btw tools/linux and tools/linux64, both have 64 bit binaries for dfu-utils, maybe point the scripts to tools/linux
and have linux32 & linux64 directories. script to copy the appropriate contents of directories or just link to them.
I’ve looked at the commit history for the bootloader, and the only code change since the 6th Feb is this one
https://github.com/rogerclarkmelbourne/ … 0f8d7c391c
and if you look at the code. It doesnt apply to the Maple mini. (look at the if def’s)
However I have recompiled the Maple mini, so there is a chance that I’m using a slighly different version of GCC, which may be causing problems (the binary is definitely different)
