OSX - No upload via dfu

Apple Mac OSX
keypunch
Posts: 67
Joined: Tue Aug 02, 2016 2:26 am

Re: No upload via dfu

Post by keypunch » Mon Nov 28, 2016 3:30 am

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

danieleff
Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: No upload via dfu

Post by danieleff » Mon Nov 28, 2016 8:28 am

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.
Use the tools/linux[64]/maple_upload script to upload. This script will:
  1. Reset the board by sending a special sequence to it on Serial USB. (dummy_port is important.)
  2. Run dfu-util as you did
keypunch wrote: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.
Here are bootloader binaries: https://github.com/rogerclarkmelbourne/ ... 1/binaries
Use maple_mini_boot20.bin for your MM clone.

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

Re: No upload via dfu

Post by keypunch » Tue Nov 29, 2016 12:00 am

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.
Use the tools/linux[64]/maple_upload script to upload. This script will:
  1. Reset the board by sending a special sequence to it on Serial USB. (dummy_port is important.)
  2. Run dfu-util as you did
Daniel,

One of the handful of issues I am still trying to sort out is a file not found that seems related to what you have noted as a special sequence sent on the USB interface that should run. My sense is the file not found error results in the special sequence not being sent to the MM. I do not believe this is due to my error, but need to look into in the cause. This will help me determine if this error is caused by my first time using the Arduino_STM32. I will need more than few days before I can even look at the issue deeper due to some none computer things I need to do. Initial simple follow up to the file not found was not what I would normally expect. Hence, I really do need to look at in a methodical manner to see what is the issue (me and/or the code).

There was another issue most interesting that I have done some deeper analysis of on Saturday. I still need to do more analysis of that issue as well given the nature of the issue. The issue could be a mix of, or one of, the Arduino 1.6.13 IDE, for Linux 64 bits, and/or Arduino_STM32
danieleff wrote:
keypunch wrote:
keypunch wrote: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.
Here are bootloader binaries: https://github.com/rogerclarkmelbourne/ ... 1/binaries
Use maple_mini_boot20.bin for your MM clone.
Thanks Daniel for this information.

I may not have expressed myself clearly. I like to be able to download from the MM clone the bootloader that is on it already on the MM clone as I received. This in case I have a need to load the bootloader that was on the MM clone as it was out of the package that arrived. There may be some reason I may have that may mean I want to load the original MM clone bootloader after I load the Use maple_mini_boot20.bin for your MM clone. you kindly noted.


Regards,

John L. Males
Toronto, Ontario
Canada
28 November 2016 17:45 - 19:00

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

Re: No upload via dfu

Post by RogerClark » Tue Nov 29, 2016 12:05 am

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
I think I have a solution for this, but have not had time to recompile the bootloader

Most boards have jumpers for boot0 and boot1

Boot1 only makes any difference when boot0 is HIGH.

So we can use boot1 independently as a way to force the board to say in DFU mode (like the Maple mini does with its "button")

So if you fancy having a go at building the bootloader it would be really simple to just change / add the BUTTON definition for the BluePill and make it the Boot0 pin

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

Re: No upload via dfu

Post by RogerClark » Tue Nov 29, 2016 12:11 am

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

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

Re: No upload via dfu

Post by keypunch » Tue Nov 29, 2016 3:00 am

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

Code: Select all

Bus 002 Device 003: ID 1eaf:0004
of any concern to what Stephen receives as a USB ID:
getting the MM(blue/red pills as well) into dfu mode (lsusb 1eaf:0003) seems a bit awkward.
As far as the dfu-util is concerned for the board USB ID info is there information provided in the Arduino config used to enable the IDE to know about the STM32 boards that is related to the USB ID information and/or has to match?

I know there are boards with a Boot1 and Boot2 jumper. I will be receiving a few boards in week or so that have such jumpers. Is my understanding correct that the MM or MM clones do not have a Boot1 or Boot2 jumper? Hence Roger's idea using the reset button to place the MM in DFU mode as a form of the Boot1 jumper of those boards with a jumper?

@Roger. There appears to be a problem with the scripts/binaries that are meant to switch the MM to DFU mode. If this bears out in my analysis maybe there is were the fix should be. I really do not want to have to press the boot button or change jumpers each time to load a sketch to the MM. I will have a ST-Link and USB to TTL Serial adaptor, but still "few weeks" to appear from the "slow boat". Still, being able to load the sketch this via the USB serial if possible for the MM would be helpful. My experience and knowledge is still too limited to know the pros, cons, et al that may need consideration for other boards. I like to see if there is a problem with the Arduino_STM32. I suspect a possibility. I suspect some may not be aware or do not have the issue. Until I have some time later in week to spend I will not know if there are some issues or the issue is "me"!

@Roger. I have no idea if I will to need to reload a MM Clone to the original bootloader the board arrived with. My standard approach of such matters is to have the original firmware in case it is needed for some unforseen reason. Hence why I like to copy the bootloader off the MM clone I have "in case" such a need arises.The option to build from the LeafLabs source is helpful as is knowing the MM Clone may be older firmware. I have learned in my IT line of work I did for years to keep my options open which is based on my years of working with embedded and other systems with respect to their firmware. The need is never known in advance, but when the need is there it is usually important to have such reference images from the device. I just had a similar conversation with a developer today needing advise about a complex database. Similar in same way as need for copy of the MM Clone firmware arrived with except for database need to copy and reasons for the copy and why that copy is needed for what he needs to do. The parallels are more similar than not for same reasons and the same not sure why this is needed. I have seen why this has been needed way too many times in my IT career. Need on % basis low, but when the need arises it is very important.

Just back from grocery shopping hour ago. Time to make a diner. This means maybe I have chance to reply again if need be before I am [/offline] for other matters to attend to for couple days.


Regards,

John L. Males
Toronto, Ontario
Canada
28 November 2016 21:00 - 22:00

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

Re: No upload via dfu

Post by RogerClark » Tue Nov 29, 2016 3:26 am

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

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

Re: No upload via dfu

Post by RogerClark » Tue Nov 29, 2016 5:06 am

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.

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

Re: No upload via dfu

Post by keypunch » Tue Nov 29, 2016 6:17 am

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
To clarify the Maple upload script that sends the magic sequence to exec the bootloader will work with the MM clone firmware, the MM new firmware, or either? In other words is there a need to have the new bootloader you have created for the Maple upload script magic sequence to exec the bootloader?

If I can upload a sketch to the MM, all be it having to use the "Reset" button to catch the DFU moment before the bootloader tranfers control to the sketch mean I have correctly set the IDE COM port (serial USB) that is connected to the MM USB connector? If yes, then it is possible there is a bug in the upload scripting that results in the magic sequence not being sent. I ask to make sure a USB to TTL Serial adaptor is not what was being referred to.
RogerClark wrote: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
Is the "Button" the one labled "but=32" on the MM clone?

"Reset" button on MM is not Boot0 nor Boot1?

As FYI I fully expected I need to use a ST-Link or USB to TTL Serial adaptor to load a new bootloader. It will be a few weeks until I have one or other first and other close beind via the "slow boat".
RogerClark wrote:I pull boot1 low via 10k on my MMs if I want to upload via serial
Thanks for this. I will need how to do this later and likely to research the exact how this is wired and if I cannot figure it out I will ask only then. I do not want to try this now when I still only have one MM clone to work with.
RogerClark wrote:The Boot1 think on the Jump link is just for non MM boards as they only have a reset button not a User Button.
Understood. As noted prior I have some boards of real interest to me I should have in week or less if Canada Post "functions". The of interest boards have the Boot0 and Boot1 jumpers. It is not unusual for first class mail between cities in Canada only a few hundred miles apart to take over 3 weeks to be delivered. Simple mail of single sheet folded into envelope mail. I kid not. Between points in same city can take 3-4 days or more way too often. Hence "functions".
RogerClark wrote: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
I was searching for how to enter perpetual bootloader and not able to find on Saturday and Sunday. I knew I read about it in last few months. Thank you so much for this information. I am going to try it just to make sure I understand correctly and that the existing bootloader on the MM clone I have does so.
RogerClark wrote: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)
Understood. I had previously understood from my prior reading of past few months. Helpful you noted as helps ensure I am correctly recalling what I have read previously sometime in last few months.
RogerClark wrote: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
Understood and makes complete sense in implementation. I like the concept for many reasons.
RogerClark wrote: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.
Is this why I see something like 2K ofRAM use for a simple blink program?
RogerClark wrote:On the new bootloader it free's up all the RAM and only runs sketches from flash
As you know on an AtMega238 only 200K or so of RAM is used for Blink. I had read about the all RAM is available with the New Bootloader. The all RAM available feature of New Bootloader may just allow me to use a MM for what I need for my special personal project.
RogerClark wrote: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
Understood.

Roger, I understood all of what you wrote just fine. The only part that I will need to learn more about via my own research is the pull low/high in how is done. I understand the logic aspect. The reason I say state these points is, for example, the points related to the MM you stated might be helpful if were in the MM/MM Clones Wiki. This would mean structuring the points in an order and prose that would be understood for new people (not newbies of programming and such). The Wiki is one of the places I looked first, then an internet search to find the answers or info I needed and hope to find. I am not suggesting you do the prose work. I am suggesting if you and others feel it would make sense to do? If yes then me and/or others can create what makes sense and let others review/comment before it is added to the Wiki(s). It is just a suggestion, not a request. I know you have alot on your plate. Hence, why I think others could do so and then review the additions via a new topic opened for that purpose.

Regards,

John L. Males
Toronto, Ontario
Canada
29 November 2016 00:00 - 01:08/01:16

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

Re: No upload via dfu

Post by RogerClark » Tue Nov 29, 2016 7:07 am

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)

Post Reply