OSX – No upload via dfu

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

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

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

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…

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

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

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

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

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

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

Hello Stephen,

I have a ST-Link and two USB to TTL Serial adaptors on way. They have not arrived yet. Likely a few more weeks on the “slow boat”.

I have a couple very interesting boards I ordered a couple weeks ago. The STM32F103C8T6 boards I ordered I am really hoping will be what will be my close to ideal (as long as I do not exceed the 20K RAM, as I will not exceed the flash with the code I will need to develop). These interesting boards just arrive on the west coast on weekend. ETA with “trusty” (cough cough) Canada Post is those board should be here in a week. Three Baite Maple Minis are on way still, but ETA unknown.

The STM32F103 board (arrived last Friday) I had issues with is a MM clone that looks exactly like the Baite MM. It is not a Red or Blue pill board. My fingers slip on the small reset button so I understand the reset button challenges.

I do appreciate your noting the pins I will need to use for the ST-Link and USB to TTL Serial. That will be most helpful once at least one of the USB or ST-Link adaptors arrives. And once both have arrived. I will not just want to test them, but use so I understand their use.

I just cannot remember from my past months of reading and not able to find yet (how happens most of time seems) in searching a few times in last day if one has to always use the “reset” button to allow dfu-util to load the bin to board. I do know that to load the alternate V2.0 STM32duino firmware for the MM I need to do so with the ST-Link or USB to TTL serial. Until one of those adaptors arrive I have to use the “reset” button. I need find what I am sure exists about this (even if it says load the STM32duino V2.0 BL) or what I need to do that I have forgotton in my reading over the last few months. I am assume (from my memory or what I have read over the last few months) unlike the Red/Blue pill R10 issue, the R10 issue or similar does not exist with the MM clones.

I really hope there is a bootloader on a very interesting STM32F103C8T6 board and a STM32F407VET6 board to experiment with that will should arrive in week or less and will at least work in the STM32duino mode.

I also need to figure out if, and if so, how to download the existing bootloader in case I need or wish to load it back onto the board.

Regards,

John L. Males
Toronto, Ontario
Canada
27 November 2016 22:30

keypunch wrote:
I just cannot remember from my past months of reading and not able to find yet (how happens most of time seems) in searching a few times in last day if one has to always use the “reset” button to allow dfu-util to load the bin to board.

danieleff wrote:keypunch wrote:
I just cannot remember from my past months of reading and not able to find yet (how happens most of time seems) in searching a few times in last day if one has to always use the “reset” button to allow dfu-util to load the bin to board.

zmemw16 wrote: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

There is probably an original binary kicking around, but I’m not sure why you’d want to use it as the new verison is better in many ways

The old leaflabs repo for the bootloader is here

https://github.com/leaflabs/maple-bootloader

So you could rebuild it from their code, but the bootloader that comes on the board from china could be even older

Is a USB ID for the MM clone I have of:

Bus 002 Device 003: ID 1eaf:0004

You don’t need to set a jumper or press a button if things are working OK

After the compile is finished, Maple upload script gets run by the IDE which then sends a magic sequence to the USB Serial in the sketch, which causes it to JUMP to zero and exec the bootloader.

But if you have not selected the COM port (Serial USB) for the sketch code this is not possible as the upload script won’t know which port to send the magic number to

The idea with Boot1 is for non MM boards. On the MM the “Button” is connected to boot0 and boot1 is floating. Boot1 floating is a hardware error in the design and I have found it prevents the board going into its internal serial uploader which is needed if you want to reflash the bootloader on the MM

I pull boot1 low via 10k on my MMs if I want to upload via serial

The Boot1 think on the Jump link is just for non MM boards as they only have a reset button not a User Button.

On the MM it can be tricky to enter perpetual bootloader because the User button is not boot0, so if you press and hold while pressing and releasing reset, you end up in the STM32’s own internal Serial bootloader not the MM bootloader

You have to press and hold the User Button after you have released the reset button, but its a limitation of the hardware not the bootloader

Just to reiterate

DFU is only available for a few seconds after the bootloader starts (Unless you can press the button on the MM after pressing reset)

Note. In the original firmware, if you hold down the button too long it is also ignored (I didnt write the bootloader so this is by design by Leaflabs)
The newer bootloader is better, I think you can hold the button in and it stays in DFU mode.

If you don’t press the button, after a few secs there is no DFU upload data, the bootloader checks if there is a sketch in flash and if so it jumps to the sketch. If no sketch is present, I think the booloader resets and tries again

Note the old / original bootloader checks for a sketch in RAM as well as Flash, but the RAM option was removed as its virtually impossible to fit a meaningful sketch in and it also wastes 3K of the 20K RAM doing this, as the bootloader has to preserve its vars in RAM and Leaflabs allocated 3K to the bootloader for this.

On the new bootloader it free’s up all the RAM and only runs sketches from flash

NOte. The bootloader only provides DFU, not Serial
The sketch only provides Serial (not DFU)

The bootloader does not run after the code jumps to the sketch, and vice versa

Just re-tested the new bootloader, and you need to press the User Button straight after you release the Reset button, otherwise it doesnt get recognized by the bootloader code.

One other trick I do on windows, to upload is…
Unplug the board (Maple mini or BP etc)
Tell the IDE to upload
When the IDE has finished compiling and is trying to upload.
Plug the board in.

This seems to work because dfu-util on Windows seems to have a timeout while it waits for a DFU device to appear, but unfortunately I don’t think the Linux version does this.

Roger thank you for your excellent reply. Your reply confirms some parts I know I have read, some I read and could not remember, and some new elements.

RogerClark wrote:You don’t need to set a jumper or press a button if things are working OK

After the compile is finished, Maple upload script gets run by the IDE which then sends a magic sequence to the USB Serial in the sketch, which causes it to JUMP to zero and exec the bootloader.

But if you have not selected the COM port (Serial USB) for the sketch code this is not possible as the upload script won’t know which port to send the magic number to

John

I don’t know what bootloader the MM clones have installed. But it seems to be an old one, possibly dating back to 2013 or 2014.

Re: MM reset button

The MM circuit is on github

https://raw.githubusercontent.com/leafl … lemini.pdf

And I think most clones are very similar to the original (though other people know more about this than I do)

Reset, is connected to Reset on the MCU,
User button is connected to Boot0

Re: Magic sequence

Nothing has changed in the new bootloader in this regard, as its the sketch that receives the sequence from the maple-uploader

Re: Bootloader versions

The new bootloader has changes to allow for compiler optimisation for size and more recently to work with gcc 4.9 and newer
Optimization for size, saved some Flash. (I think saved 8 k of flash)

Re: Bugs in upload script

There are timing issues, between the USB bus being reset and the DFU being available and dfu-util seeing this.

There is a configurable delay in the OSX version to handle this, I can’t recall if I did the same thing for Linux

The latest bootloader also has an extra mode where the sketch can lock it into DFU mode using the battery backed RAM which survives reset as long as power is maintained.

However I’ve not updated the core code to set the RAM location yet, so I’ll try to remember to do that soon, but I then need to test it on multiple boards to make sure it works.

(And as you can imagine I have very little spare time support this)

Hello Roger,

Sorry I have had a number of “interrupts” due to reasons for my important personal STM32 project. Compounding this is various items I ordered last Fall that should have arrived mid to later December 2016 eitehr have not arrived or are taking 3-4+ months to arrive. Examples are Baite Maple Mini Clones just arrived in last few days as well as U*SB to TTL Serial adapter. The STLink adapter still has not arrived. The orders not arriving or taking months to eitehr arrive or still not has taken much more time to address than I could have imagined.

WRT my expeiences with the first Baite Like Maple Mini Clones I had I decided to wait for the Baite Maple Mini Clones to arrive before I tried again in case these was some “other” unknown issues with the Looks like a Baite Maple Mini Clone.

I decided earlier today to see what using a Baite Maple Mini Clone with the IDE from a clean room test would result in. This took some time as there appears to be multiple issues that compound matters. Basically same issues as prior noted by me, and some other issues. I did solve the issues in some fast and dirty ways just to save time and prove most of the issues. I still have one issue to “prove” that is not listed mentioned i this topic as I never had a situation to present the possible cause.

In the findings today no differences between the Baite Maple Mini Clone and the look alike Bait Maple Mini Clone. Both Maple Mini Clones types I have work as expected exclusive of one outstanding issue I still have to fully prove and I fully expect will be an issue that is not specific to the board being used by me or in wider scope other boards that otherwise “work” fine.

I have also started making some extensive changes to some of the code related for these issues so far that I can address with code fixes and some other types of fixes. The question I have is what topic do you suggest I post the issues, fixes, and any issues can duplicare and unable to figure out a fix? Do you wish these to be seperate by types of issues I found and have a possible fix for? For issues I cannot figure out a fix for do I post those in a seperate topic or in same overall topic of the issues I found and also have possible fixes for?

As an FYI, due to the nature of the interrupts I am having that are the basis for the important personal STM32 project I may have unexpected delays in my replies. My applogies in advance, but I have no control over these “interrupts” nor the nature of these. I will reply. Perhaps not as soon as even I would like to reply, let alone otherwise.

Regards,

John L. Males
Toronto, Ontario
Canada
03 March 2017 04:20 EST
03 March 2017 05:48 EST (Typo Correction and correct time to EST not UTC)