Sketch Upload

Hi all,

I have Arduino 1.6.5 running OK on Ubuntu 14.04 and uploading to Maple Mini.

As I have not been working much on the Maple recently, I would like to ask a couple of questions:

1. Is there any way to have auto-reset work for the Maple like it does for other Ardunino boards, so that its not neccessary to set the Maple to Perpetual Bootloader Mode before sketch upload, and then perform manual reset after sketch upload to start the sketch running?

2. How long are other Linux users finding that the upload process takes with DFU? Even a simple sketch takes ~10 seconds for me. Is that normal? (output below)
Sketch uses 12,556 bytes (11%) of program storage space. Maximum is 110,592 bytes.
Global variables use 3,104 bytes of dynamic memory.
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 a 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]

Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device

Download [ ] 0% 0 bytes
Download [= ] 7% 1024 bytes
Download [=== ] 15% 2048 bytes
Download [===== ] 22% 3072 bytes
Download [======= ] 30% 4096 bytes
Download [========= ] 37% 5120 bytes
Download [=========== ] 45% 6144 bytes
Download [============= ] 52% 7168 bytes
Download [=============== ] 60% 8192 bytes
Download [================ ] 67% 9216 bytes
Download [================== ] 75% 10240 bytes
Download [==================== ] 82% 11264 bytes
Download [====================== ] 90% 12288 bytes
Download [======================== ] 97% 12556 bytes
Download [=========================] 100% 12556 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

Paul

Have you tried using the new bootloader. AKIK, upload speeds are now faster.

Re: auto reset

I’m sure I posted about this issue for OSX but its basically the same.

The upload script just resets the USB device but this is not enough to cause the USB code on the board to reset into the bootloader (the code that does this is part of the sketch).

Basically, the USB serial code looks for DTR being toggled and a special sequence of chars being sent. ( something like “LEAFLABS”)

On windows this is done in a jar file to which we don’t have the source

But I should be fairly trivial to write a small executable for both Linux and OSX that sets DTR and sends that sequence.

I don’t generally use OSX or Linux, so I am not an expert in writing code to control a serial device, but I know there are other people like Rick and Andy who are Linux whiz kids who could probably point us in the right direction . The problem is that neither rick not andy use the Maple mini.

Same problem on my Ubuntu, perpetual mode for sketch upload and reset after upload. Very boring.

This is supposed to be fixed now.

there is a utility called upload_reset which gets passed the com port of the board, and it sends the magic reset sequence,

I’m sure I’ve posted the instructions in another thread, but…

open a terminal window
Go to /tools/linux

run ./upload_reset YOUR_COM_DEVICE 750


I also had always to go to perpetual mode before uploading, but the actual upload was then very quick (<1sec for small sketches).

Today, I finally discovered that it was still using an old version of Arduino_STM32 which was still lying in ~/sketchbook/hardware, while my new version was in the arduino-1.6.5/hardware directory

After removing the old version, the upload-reset would now work well when setting port to /dev/ttyACM0. But I also noted that the upload was much slower (13sec for the same sketch). As it turns out, the old (fast) version called Ubuntu’s own dfu-util, while the new (slow) version would use the dfu-util in Arduino_STM32/tools/linux/dfu-util. So after changing maple_upload in the new version to call /usr/bin/dfu-util it got fast again.

The only problem which remained, was that I still had to push reset manually after each upload. That was solved when adding the option -R to the dfu-util call at the end of the maple_upload script. The Maple Mini now automatically resets after the upload has finished.

The only problem which remained, was that I still had to push reset manually after each upload. That was solved when adding the option -R to the dfu-util call at the end of the maple_upload script. The Maple Mini now automatically resets after the upload has finished.
I was having the same problem needing to manually reset the board after each upload. Adding -R to line 40 of maple_upload fixed it.
${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} ${dfuse_addr} -R

Guys

I wasnt aware that the reset was missing from the end of the dfu util command line

I will update the repo.

Its interesting that Ubuntus version of dfu util is faster, AFIK the version that we have was built from the latest sources.

Also, if you have not already done this, I’d recommend you update to the new bootloader, it is faster than the old one.
There is an updater sketch, for the Maple mini in the stm32duino-bootloader repo ( use at your own risk, but it seems really stable and no one has reported having any problems with it before)

OK

Those changes should no be in the repo

Hi All;
Updated to linux mint 17.3 64bit and now I am having a strange problem

java.io.IOException: Cannot run program “/home/doc/Arduino/hardware/Arduino_STM32/tools/linux/maple_upload”: error=13, Permission denied
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at java.lang.Runtime.exec(Runtime.java:485)
at processing.app.helpers.ProcessUtils.exec(ProcessUtils.java:11)
at cc.arduino.packages.Uploader.executeUploadCommand(Uploader.java:115)
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:159)
at processing.app.debug.Compiler.upload(Compiler.java:166)
at processing.app.Sketch.upload(Sketch.java:1167)
at processing.app.Sketch.exportApplet(Sketch.java:1141)
at processing.app.Sketch.exportApplet(Sketch.java:1113)
at processing.app.Editor$DefaultExportHandler.run(Editor.java:2380)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: error=13, Permission denied
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:248)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
… 11 more
I have reset permissions on each file I think it maybe the arduino user/group assignments? IDE works great on mega2650 etc but not stm.
blink compiles ok but it’s the upload that causes the problem.
any help would be appreciated
thanks
Doc

Does the file (maple_upload) exist at that location?
Is it marked as executable?

Please open a terminal and type:

ls -la /home/doc/Arduino/hardware/Arduino_STM32/tools/linux/

and post the output here.

Here is the results
drwxrwxrwx 5 doc doc 4096 Jan 15 21:03 .
drwxrwxrwx 6 doc doc 4096 Jan 15 21:03 ..
-rw-rw-rw- 1 doc doc 351 Jan 15 21:03 45-maple.rules
drwxrwxrwx 2 doc doc 4096 Jan 15 21:03 dfu-util
-rwxrwxrwx 1 doc doc 613 Jan 15 21:03 install.sh
-rw-rw-rw- 1 doc doc 970 Jan 15 21:03 maple_upload
-rw-rw-rw- 1 doc doc 58 Jan 15 21:03 readme.txt
-rw-rw—- 1 doc doc 90 Jan 15 21:03 serial_upload
drwxrwxrwx 2 doc doc 4096 Jan 15 21:03 stlink
-rw-rw—- 1 doc doc 1207 Jan 15 21:03 stlink_upload
drwxrwxrwx 2 doc doc 4096 Jan 15 21:03 stm32flash
-rw-rw—- 1 doc doc 7946 Jan 15 21:03 upload-reset
-rw-rw—- 1 doc doc 2812 Jan 15 21:03 upload_router

from my limited Linux knowledge it should be ok??
thanks

Its not marked as executable.

Please type:

chmod +x /home/doc/Arduino/hardware/Arduino_STM32/tools/linux/maple_upload

and try to upload again.

Thanks for all your help!!!
I now have a new error- in the dfu-util section. According to the mint package manager dfu-util is installed also according to apt-get I have the latest version installed. I am running arduino ide from downloaded and uncompressed 1.6.5 arduino ide.
.
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
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: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: No DFU capable USB device available

I am using a current download of the Arduino_STM32_Master download. Port is listed as /dev/ttyACM0 in arduino ide
thanks

Just uninstall the dfu-util using the Mint package manager.

The package manager will not know about the version copied into Arduino/hardware/STM32/ …

I blew my Win8.1 installation and installed Mint Cinnamon 17.3 64-bit yesterday. A few path issues as I have 3 ArduinoIDE versions installed and a couple of file permissions.

With Maple Mini on bootloader 2.0, everything is compiling and downloading perfectly. Using minicom, the serial session is stopped during downloads and automatically restarts after the download: Quiet convenient.

Ray

With Maple Mini on bootloader 2.0, everything is compiling and downloading perfectly. Using minicom, the serial session is stopped during downloads and automatically restarts after the download: Quiet convenient.

ok that’s twice in an hour, i tried using putty, results not pretty. finding minicom … …

stephen

zmemw16 wrote:With Maple Mini on bootloader 2.0, everything is compiling and downloading perfectly. Using minicom, the serial session is stopped during downloads and automatically restarts after the download: Quiet convenient.

ok that’s twice in an hour, i tried using putty, results not pretty. finding minicom … …

stephen

Thanks for the suggestion but when I uninstalled dfu-util I got same error Tried minicom -s now trying to figure out which settings to use. Just wish I could remember how I setup stm32 in mint 16 and ardunio 1.0. I have a couple of mini’s coming from Ali will try with one of them when they arrive. For now I am using an original maple and maple r5 that I have had for a while. So I think getting the dfu-util is probably the way to go???
With the mini will I use dfu-util or just a serial port??
could I possibly have a link missing? between the ardunio ide and dfu-util ?? or perhaps another permission problem ?? or group assignment ??

thanks
Doc

wyzarddoc wrote:Thanks for the suggestion but when I uninstalled dfu-util I got same error Tried minicom -s now trying to figure out which settings to use. Just wish I could remember how I setup stm32 in mint 16 and ardunio 1.0. I have a couple of mini’s coming from Ali will try with one of them when they arrive. For now I am using an original maple and maple r5 that I have had for a while. So I think getting the dfu-util is probably the way to go???
With the mini will I use dfu-util or just a serial port??
could I possibly have a link missing? between the ardunio ide and dfu-util ?? or perhaps another permission problem ?? or group assignment ??

thanks
Doc

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: No DFU capable USB device available

This is because the newer dfu-util 0.8 is looking for firmware.dfu file not firmware.bin.
To be able to upload a BIN file, it needs extra argument which tell where to place the binary using “–dfuse-address <address>”
In my case, under STM32F4, I’ve added that to boards.txt/platform.txt. That way, what ever the version of dfu-util, it will work.
The other workaround, as explained here, is to stick with dfu-util-0.7 …

For a Maple Mini, here is how a good upload from Linux appears:

<...>
build602781049245864709.tmp/board.cpp.o /tmp/build602781049245864709.tmp/core.a -Wl,--end-group
/home/ray/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-objcopy -O binary /tmp/build602781049245864709.tmp/BlinkNcount.cpp.elf /tmp/build602781049245864709.tmp/BlinkNcount.cpp.bin

Sketch uses 14,092 bytes (11%) of program storage space. Maximum is 122,880 bytes.
Global variables use 2,560 bytes of dynamic memory.
/home/ray/Arduino/hardware/STM32/tools/linux/maple_upload ttyACM0 2 1EAF:0003 /tmp/build602781049245864709.tmp/BlinkNcount.cpp.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]

Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device

Download [ ] 0% 0 bytes
Download [= ] 6% 1024 bytes
Download [=== ] 13% 2048 bytes
Download [===== ] 20% 3072 bytes
Download [====== ] 27% 4096 bytes
Download [======== ] 33% 5120 bytes
Download [========== ] 40% 6144 bytes
Download [=========== ] 47% 7168 bytes
Download [============= ] 54% 8192 bytes
Download [=============== ] 60% 9216 bytes
Download [================ ] 67% 10240 bytes
Download [================== ] 74% 11264 bytes
Download [==================== ] 81% 12288 bytes
Download [====================== ] 88% 13312 bytes
Download [======================= ] 94% 14092 bytes
Download [=========================] 100% 14092 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode


Hey,
Thanks mrbrunette that worked. I still need to start the sketch compiling then hit the reset on the maple. If I hold my mouth right and the phase of the moon is right it will download and run!!!! thanks again for all your help
Doc

wyzarddoc wrote:Hey,
Thanks mrbrunette that worked. I still need to start the sketch compiling then hit the reset on the maple. If I hold my mouth right and the phase of the moon is right it will download and run!!!! thanks again for all your help
Doc

I think the only way to guarantee near 100% success is to upload using SWD (STLink).

I find even the built in Serial bootloader less than 100% reliable connecting, as sometimes the Red Pill doesn’t seem to reset cleanly when I press the Reset button.

Using a SW bootloader its always going to be possible to hang the process or in such a way that the bootloader no longer gets activated. e.g. disable all interrupts and go into a tight loop.

Come to think of it, even SWD is not foolproof as you can disable the SWD pins in software, so unless your SWD programmer actively resets the MCU and your programmer software is set to Connect Under Reset, that can still fail.

RogerClark wrote:I think the only way to guarantee near 100% success is to upload using SWD (STLink).

I find even the built in Serial bootloader less than 100% reliable connecting, as sometimes the Red Pill doesn’t seem to reset cleanly when I press the Reset button.

Using a SW bootloader its always going to be possible to hang the process or in such a way that the bootloader no longer gets activated. e.g. disable all interrupts and go into a tight loop.

Come to think of it, even SWD is not foolproof as you can disable the SWD pins in software, so unless your SWD programmer actively resets the MCU and your programmer software is set to Connect Under Reset, that can still fail.