I was experimenting with a PWM program flashing LED2 and using Button to change the duty cycle and printing the duty cycle to the serial monitor. I was loading the program each time to RAM. A few times it didn't seem to finish uploading to the board; the IDE hung before completion without printing any errors (text in red) but without reaching the Resetting USB to switch back to runtime mode message. All this time the board was installed on COM17. I could upload the program to RAM, view the output to the serial monitor, all with the IDE set to COM17 and Leaflabs Maple 3+ to RAM.
Then when the program was finished I tried to upload to flash, and it hung before completing, and the program was not loading. I disconnected and reconnected the board several times, but the program would not work and the board was apparently not recognised any more by the PC. The only COM port listed in the IDE was COM3 which is used by some other software. The Maple was not listed in Device Manager.
Then I put the board into perpetual boot mode, and then it would be recognised by the PC and I could download programs to it on COM3 (RAM or flash), but ONLY when the board is first put into permanent bootloader mode and the IDE set to COM3. Once the upload is completed and the program starts running the board is no longer recognised on COM3, but instead on the other COM port (now COM8 because I reset it in Device Manager).
The board remains unprogrammable, unless it is first put into permanent bootloader mode and the COM port changed in the IDE.
Does this mean the bootloader program is defective? What is the cause of these problems uploading - could it be that the USB chip is defective or the USB contacts on the board are defective? I never moved the board or touched the wires at the time the uploads hung. I have never had any trouble with this USB cable, and have never had any such problems programming arduinos.
This is what is in the monitor window from the last upload:
Going to build using 'armcompiler' (ARM)
Compiling core...
No libraries to compile.
Compiling the sketch...
Linking...
Computing sketch size...
Q:\Temp\build6269183082864481049.tmp\PWM_example_BM.cpp.bin :
section size addr
.data 16016 0
Total 16016
Binary sketch size is reported above. Check it against a 108000 byte maximum.
Loading via dfu-util
Resetting to bootloader via DTR pulse
java.io.IOException: No error in nativeDrain
at gnu.io.RXTXPort.nativeDrain(Native Method)
at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201)
at processing.app.Serial.write(Serial.java:470)
at processing.app.Serial.write(Serial.java:492)
at processing.app.debug.DFUUploader.emitResetPulse(DFUUploader.java:170)
at processing.app.debug.DFUUploader.uploadViaDFU(DFUUploader.java:100)
at processing.app.debug.DFUUploader.uploadUsingPreferences(DFUUploader.java:57)
at processing.app.Sketch.upload(Sketch.java:1473)
at processing.app.Sketch.exportApplet(Sketch.java:1405)
at processing.app.Sketch.exportApplet(Sketch.java:1368)
at processing.app.Editor$45.run(Editor.java:1965)
at java.lang.Thread.run(Thread.java:619)
Searching for DFU device [1EAF:0003]...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=320
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Hello Bhante,
Throughout my work with maple I've also noticed this problem and it seems to appear a lot with this version of the bootloader and IDE. I also put the olimexino-stm32 in perpetual bootloader mode manually every time, the IDE waits more before uploading, but at least it works.
I'm not sure about the java exception part, but other than that the output maple gives you is pretty standard.
Best regards,
Maria/OLIMEX
Quote from: maria_olimex on April 03, 2013, 08:37:38 AM
I've also noticed this problem and it seems to appear a lot with this version of the bootloader and IDE.
Given that the bootloader is not working properly, what are your plans to fix it, and what is your timescale for implementation?
Quote from: maria_olimex on April 03, 2013, 08:37:38 AM
I'm not sure about the java exception part, but other than that the output maple gives you is pretty standard.
As a general rule when analysing problems the output which is exceptional is the part which should be focussed on. That part which is standard is of no interest, except in so far as it can be combined with the exceptional part to help focus in on what is going wrong.
This problem of the bootloader not working is irritating. I am having to download firmware multiple times before it will install properly, and the information output is not even consistent from one download to the next, even when it works. Attached are the outputs from three successive downloads made one immediately after the other, without any changes to the code whatsoever. All three outputs are different.
http://up.picr.de/14073780xp.jpg (http://up.picr.de/14073780xp.jpg)
http://up.picr.de/14073781ap.jpg (http://up.picr.de/14073781ap.jpg)
http://up.picr.de/14073782dl.jpg (http://up.picr.de/14073782dl.jpg)
Also the method for entering the perpetual bootloader mode is not very satisfactory, as the timing when the 2nd button has to be pressed down has to be exactly right, and the timing when it is released has to be exactly right, and often it too requires several attempts. The flashing LED signals are not very well thought out to tell you when to press and release.
Hello Bhante,
I understand your frustration with the uploading process as I too experience it every time. However, we are not responsible for the development of the MAPLE IDE or the bootloader. You can see all the MAPLE IDE documentation, contact info and updates here:
http://leaflabs.com/docs/
or their forum (active):
http://forums.leaflabs.com/
You can get the latest sources from here:
https://github.com/leaflabs/
There is an explanation on the site about setting up libmaple and GCC, possibly in combination with an IDE like Eclipse. I have not tried it, however, and cannot comment on it.
http://leaflabs.com/docs/unix-toolchain.html#unix-toolchain
Now, about the outputs you get - your second and third attempt at uploading were obviously successful. The red lines showing warnings about parts of the code are, to my knowledge, the IDE displaying compiler/linker output incorrectly. All the warnings about the reset/bootloader are there because the PC attempts to send a signal, which should reset the board into bootloader mode automatically but almost always fails and then (most times) tells you to do it manuall.
You can always see the full output from the compilation process in your %TEMP% folder. Every time you create/open a sketch new folders are created there:
build<random_number_1>
console<random_number_2>
untitled<random_number_3>
Best Regards,
Maria/OLIMEX