No upload via dfu

User avatar
Kenjutsu
Posts: 113
Joined: Fri May 29, 2015 8:26 am

No upload via dfu

Postby Kenjutsu » Wed Nov 16, 2016 10:54 am

Hello everyone,

My setup: OSX 10.9.5

This week I decided to move from Arduino IDE 1.6.5 to 1.6.9. Since I had multiple version of the IDE (since version 1.x), I decided to remove all of them, including any and all Arduino related directories.

I downloaded Arduino 1.6.9. and followed the installation instructions on the wiki.

I plugged in one of my Baite Maple Minis to test my setup. The MM was assigned a serial port, and already had Bootloader V2rc1 on. I tried to upload the blink example, but simply got:

Code: Select all

maple_upload cu.usbmodemfd1241 2 1EAF:0003 /var/folders/s5/cfn1c1vj7xx3q3x2gpd81m540000gn/T/build6deb9daa84ca6d09c9b0a8d0a8cab731.tmp/FirstProgAfterSTM32duinoBL.ino.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 http://sourceforge.net/p/dfu-util/tickets/

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


Tried a few more times, and a different USB cable, but nothing worked. Tried another MM, same result. I then downloaded and flashed the latest Bootloader V2 bin:

Code: Select all

./stm32flash -b 57600 -v -R -w maple_mini_boot20.bin  /dev/tty.SLAB_USBtoUART
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 9600 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 and verified address 0x08001bd4 (100.00%) Done.


Reconnected the MM, and ran dfu-util -l:

Code: Select all

Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="253-1.2.4", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="253-1.2.4", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="253-1.2.4", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"


Then ls -la /dev/tty.*:

Code: Select all

crw-rw-rw-  1 root  wheel   18,   0 Nov 14 15:49 /dev/tty.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel   18,   2 Nov 14 15:49 /dev/tty.Bluetooth-Modem


as expected, no serial port (yet)

Then I upload a simple sketch with a Serial.begin():

Code: Select all

maple_upload cu.usbmodemfd1241 2 1EAF:0003 /var/folders/s5/cfn1c1vj7xx3q3x2gpd81m540000gn/T/build6deb9daa84ca6d09c9b0a8d0a8cab731.tmp/FirstProgAfterSTM32duinoBL.ino.bin
Failed to open serial device.
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

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 http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
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   [====                     ]  19%         3072 bytes
Download   [======                   ]  26%         4096 bytes
Download   [========                 ]  32%         5120 bytes
Download   [=========                ]  39%         6144 bytes
Download   [===========              ]  45%         7168 bytes
Download   [=============            ]  52%         8192 bytes
Download   [==============           ]  58%         9216 bytes
Download   [================         ]  65%        10240 bytes
Download   [=================        ]  71%        11264 bytes
Download   [===================      ]  78%        12288 bytes
Download   [=====================    ]  84%        13312 bytes
Download   [======================   ]  91%        14336 bytes
Download   [======================== ]  97%        14676 bytes
Download   [=========================] 100%        14676 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode


Again, ls -la /dev/tty.*:

Code: Select all

crw-rw-rw-  1 root  wheel   18,   0 Nov 14 15:49 /dev/tty.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel   18,   2 Nov 14 15:49 /dev/tty.Bluetooth-Modem
crw-rw-rw-  1 root  wheel   18, 190 Nov 15 18:21 /dev/tty.usbmodemfd1241


Back to IDE and made sure the serial port is selected. Click on upload:

Code: Select all

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 http://sourceforge.net/p/dfu-util/tickets/

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


The only way I can get upload via the IDE to work is to put the MM in Perpetual Bootloader Mode. I tried several vaules for the upload-reset, with no effect. I can see that the MM is restarted by upload-reset.

So, to sum up: I can only upload via the IDE by placing the MM in Perpetual Bootloader Mode. The serial port of the MM is available, and upload-reset does indeed reset the MM.

Any ideas?

edit: I also tried the original Leaflabs bootloader, with the same problem
- Pieter

OSX: 10.12.2
Arduino IDE: 1.6.12
Blue pill STM32F103C8T6 Dev Board
Maple Mini Clones

User avatar
Kenjutsu
Posts: 113
Joined: Fri May 29, 2015 8:26 am

Re: No upload via dfu

Postby Kenjutsu » Wed Nov 16, 2016 4:38 pm

Ok, so I dusted off my old Dell laptop, installed Arduino 1.6.9 with the latest Arduino_STM32 files and the Windows drivers, and uploading via the IDE works.

I can then deduct that something OSX specific is wrong on my MacBook and that at least my MMs and BPs are fine 8-)
- Pieter

OSX: 10.12.2
Arduino IDE: 1.6.12
Blue pill STM32F103C8T6 Dev Board
Maple Mini Clones

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: No upload via dfu

Postby RogerClark » Wed Nov 16, 2016 7:43 pm

The problem is a timing issue on the mac.

you can adjust the delay time in the upload script

but if you flashes the very latest bootloader there is now a new option which is that the IDE can tell the bootloader to start in perpetual mode.

But I have not had chance to put that code into the core yet, as it could screw things up for some people.

If you are willing to change some files in the core you could give this new feature a try

User avatar
Kenjutsu
Posts: 113
Joined: Fri May 29, 2015 8:26 am

Re: No upload via dfu

Postby Kenjutsu » Wed Nov 16, 2016 8:04 pm

Thanks Roger. I'll give it a try. I tried several values for the delay in the upload script, but could not (yet) find the perfect one :(
- Pieter

OSX: 10.12.2
Arduino IDE: 1.6.12
Blue pill STM32F103C8T6 Dev Board
Maple Mini Clones

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: No upload via dfu

Postby RogerClark » Wed Nov 16, 2016 8:10 pm

If you look at this change

https://github.com/devanlai/Arduino_STM ... c081d18271

you could try adding the code to the usb in the core, to lock the bootloader into perpetual mode

Dont bother with the stuff in boards.txt if you dont want to, just remove the #ifdef from the new code so it runs all time time.

I will try this myself, later...

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: No upload via dfu

Postby RogerClark » Thu Nov 17, 2016 5:08 am

On an related point

I just tried the old bootloader on my ElCapitan machine and I seem to have the same issues that you did

With the new bootloader it uploads OK, but does not reset back into the sketch. This may be due to the changes to speed up the time between DFU completion and the sketch running, but I don't know for sure, as DFU Util sends a Reset command to the bootloader when uploading of data is finished and this triggers a reboot. Only in the new version it remembers its just done an upload, so skips waiting for another upload and jumps to the sketch (if present)
So it could be a problem with the new fast-run code, but it doesnt seem that likely

User avatar
Kenjutsu
Posts: 113
Joined: Fri May 29, 2015 8:26 am

Re: No upload via dfu

Postby Kenjutsu » Thu Nov 17, 2016 6:40 am

Thank you Roger. After making the changes, and selecting STM32duino bootloader (RTC), uploading to a PB works as expected.
- Pieter

OSX: 10.12.2
Arduino IDE: 1.6.12
Blue pill STM32F103C8T6 Dev Board
Maple Mini Clones

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: No upload via dfu

Postby RogerClark » Thu Nov 17, 2016 8:00 am

OK

I still have some problems with ElCapitan, but I need to do some more testing to find out why the sketch does not run after upload

But I will add that code change to the Master core, as I think it won't cause any issues

Cheers

Roger

keypunch
Posts: 35
Joined: Tue Aug 02, 2016 2:26 am

Re: No upload via dfu

Postby keypunch » Sun Nov 27, 2016 6:25 am

I received a MM late Friday. A few more are on the "slow boat". This one is close to the Baite, but not the Baite one. At time (Month +) ago I decided to try this version as many were happy with just to see.

I had a number of challenges. Some I suspect would be helpful to apply my Linux scripting skills to. I read many posts and FAQs here and some elsewhere to refresh my memory on what I have read and did not recall the specifics in the reading and research I have done the last few months about STM32.

I also think I ran into a few odd bugs. I need to return to the "clean room" tests to not only duplicate again (hopefully as solid at time all time), but there are variations needed to be tested to scope the issue as well. The variables to scope variations is more than a few and in math combinations takes time.

I am using 1.6.13 of the Arduino IDE and a x64 Debian based Linux. I know the OP is using OSx which means the OS is based on NetBSD. Same in some ways, very different in many ways to Linux.

I have had many parallels similar to one of the OP challenges and with same version of dfu-utils as OP and one in the Arduino_STM32 via Installation

Code: Select all

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 http://sourceforge.net/p/dfu-util/tickets/

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


Running dfu-utils as provided with the stm32 results were not encouraging:

Code: Select all

dfu-util -l
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org


Running lsusb was not encourging:

Code: Select all

lsusb
Bus 002 Device 004: ID 13fe:4200 Kingston Technology Company Inc.
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 13fe:4200 Kingston Technology Company Inc.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Running lsusb was interesting when I tried the reset button and was in the window of the LED blinking as result:

Code: Select all

lsusb
Bus 002 Device 004: ID 13fe:4200 Kingston Technology Company Inc.
Bus 002 Device 060: ID 1eaf:0003 
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 13fe:4200 Kingston Technology Company Inc.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


The above led me to try which was useful information:

Code: Select all

sudo dfu-util -l
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 dfu-util@lists.gnumonks.org

Found DFU: [1eaf:0003] ver=0201, devnum=65, cfg=1, intf=0, alt=1, name="DFU Program FLASH 0x08005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=65, cfg=1, intf=0, alt=0, name="DFU Program RAM 0x20000C00", serial="LLM 003"


Then I took what I discovered above with challenges the IDE presents:

Code: Select all

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 dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
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   [=========================] 100%        13840 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode


There is much I am skipping. There seems like possible related bugs to the above beyond the other challenges I had before I had a Blink sketch I changed loaded to the MM successfully. I make changes to the Blink sketch on purpose to know the Blink sketch I was trying to load in fact loaded and was run. Some Blink sketches loaded, but took a bit to find the pin the LED is connected to (I sorted that out with online digging a number of attempt itterations).

I did skip the Blink program for some time and tried to compile a blank sketch. The idea being to see if the USB would switch to DFU mode as reading I had done suggested once a initial sketch was loaded would allow the USB to switch for DFU sketch load. It took the above process to find what takes to load sketch, via the reset botton only thus far. The MM when arrived had a fast blinking LED when plugged in no longer blinked with the Blanl sketch. I think a blank sketch proved the point was loaded to MM!

I have been able to load my modified Blink program to prove the sketch loaded successfully after not just the above, but some other challenges and bugs. It appears, but I need to test more, there are some issues with some of the supporting elements of Arduino_STM32. I do not want to say what yet as this is new to me so I am not sure if these are my errors I have not learned from yet or bugs. Linux is not an issue for me as I have been using Linux as my only desktop system since 1999. Lets just say I have done more than configure and compiled a Linux Kernel many times. I need to dig to see if I am the error or not. What seems to allow a sketch to load and only way so far is if I press the reset button such that while the LED is blinking dfu-utils will find and will load the sketch. This is how I was able to see with "dfu-utils -l" the MM connected to the USB and how lsusb saw the MM.

Am I missing something? I do not believe I read about having to use the reset bottom on MM every time, or was the need to be one time only? My hunch is one time only based on what I think I remember reading and cannot find in all the searching I have done since discovering I need to use the reset button each time.

The other errors I have encountered need to see if just me still learning about STM32duino, or maybe some are variations of learning and issues?

Regards,

John L. Males
Toronto, Ontario
Canada
26/27 November 2016 23:55 - 01:20

P.S. I have been asked to test an application that is new, new to me, and rather complex, so I may be delayed unexpectly in replies, any STM32 issues I need to confirm as me, code or helpful inprovements. This sadly has been asked to be completed just before Christmas. Add in the reason this STM32 project is so important to me for personal reasons that can cause delays (and has more than few times) and I will do my best to respond when I able to. I appreciate everyones understanding in advance. I sure hope I have not made too many typos. I have found and corrected enough, but if there are more and do not makes sense via the human filters please do ask me to clarify. jlm

zmemw16
Posts: 983
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: No upload via dfu

Postby zmemw16 » Mon Nov 28, 2016 1:56 am

getting the MM(blue/red pills as well) into dfu mode (lsusb 1eaf:0003) seems a bit awkward.
it frequently takes me 4 or 5 attempts when i even try, press reset and button1, release reset, release button1
........................................................................ -------------- 1 ------------- ------ 2 ------- -------- 3 ---------
action '3' inside the 'first (fast) blinking' led time, success is a much slower continous blink.

with my large hands its a pain, so regardless i tend to wire up a stlink usb stick on 22/21 (22 clk 21 dat)
i also tend to connect a usb/uart module on a9/a10 as well. no supplies to them just the gnd.

stephen


Return to “Maple mini”

Who is online

Users browsing this forum: No registered users and 1 guest