Booloader/ DFU upload / reset run issues on OSX

STM32duino bootloader aka Maple bootloader
logd32
Posts: 8
Joined: Thu Sep 07, 2017 8:41 pm

Booloader/ DFU upload / reset run issues on OSX

Post by logd32 » Sun Oct 29, 2017 4:04 pm

Hi,
I still encounter issues during upload under OSX (10.11.6), to make sure this is not caused by previous changes in core or bootloader i used the current core and bootlader files from the github and uploaded the already compiled generic PC13 booloader. I tested with a "blue pill" board (modified with 1.5K res).

After uploading a first sketch (with the use of PB14 to stay in perpetual bootloader mode) i have the serial port shown ,the test sketch works.
When i upload, the board resets, bootloader starts (blinks fast), DFU recognize it since it doesnt throw error immediately, however after few seconds it complains "no dfu device" and doesnt upload.
Eventually after fidling for a long time with reset timing in the script or by pushing reset button "at the right time" i can get it to upload once, but the failure rate is still over 95%.

I found a procedure that works 100% of the time:
-connect board with PB14 low
-set PB14 high after boot.
-upload
-set PB14 low
-reset board

This way it always works. So something on OSX causes the normal upload procedure to fail, i suspect this is due to the way reset is issued before uplaoding.

Now i wonder if there is a way to replace PB14 by a flag (ex in RTC register), a flag that could be set true before DFU_ upload when the reset is caused by upload and set false after DFU_upload. Is it possible? is there a way to set this flag from USB or that the bootlaoder recognize reset issued by USB?

I have a subsidiary question regarding reset/run after upload, i noticed the board never resets nor run properly after DFU upload, it has to be reset manually.

I have tried to replace systemHardReset(); (after dfuFinishUpload();) by some LED blink and i can see this point is reached, i also tested that systemHardReset(); works fine.
So what could cause the STM32 to halt instead of resetting after DFU_upload? i dont understand he problem.
Thanks

devan
Posts: 50
Joined: Sat May 14, 2016 1:45 am

Re: Booloader/ DFU upload / reset run issues on OSX

Post by devan » Sun Oct 29, 2017 5:06 pm

There is some support in the bootloader for forcing it to remain in bootloader mode after the IDE resets it. See this forum thread for background.

Note that while the bootloader supports it, the STM32duino core must write into the RTC register to activate it when the board is reset.

If you want to try it out, you can poke around rxHook in STM32F1/cores/maple/usb_serial.cpp and add this code to set the RTC flag before it resets the board.

Code: Select all

bkp_init();
bkp_enable_writes();
bkp_write(10, 0x424C);
bkp_disable_writes();
You'll also need to include the appropriate header for the RTC somewhere:

Code: Select all

#include <libmaple/bkp.h>

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

Re: Booloader/ DFU upload / reset run issues on OSX

Post by RogerClark » Sun Oct 29, 2017 9:59 pm

Thanks @devan

I did want to add this to the core, but the community seemed reluctant to accept it ( though I cant remember why)

logd32
Posts: 8
Joined: Thu Sep 07, 2017 8:41 pm

Re: Booloader/ DFU upload / reset run issues on OSX

Post by logd32 » Sun Oct 29, 2017 10:14 pm

Thanks for the return.
I just tested, its rock solid, finally i dont use rtc backup register but i check directly rcc_flag registers at bootup to see what is the reset source. A flag is set accordingly then a statement sets no_user_jump flag true if source of reset is software.

This method never fails and it can probably handle timing variation of the different systems. i can understand some user may rely on the software reset for their stuffs but this case would be easily handled by disabling this mecanism if a bit is set in the backup register already used by bootlader (10) for setting bootlader into perpetual model from software.

Anyway now upload success is 100% on my OSX against 5% before.
N.B. reset and run after upload now works normally, i only added few led strobes after dfuFinishUpload so unsure why it failed previously.

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

Re: Booloader/ DFU upload / reset run issues on OSX

Post by RogerClark » Mon Oct 30, 2017 12:34 am

Cool

hanyazou
Posts: 43
Joined: Fri May 05, 2017 2:38 am

Re: Booloader/ DFU upload / reset run issues on OSX

Post by hanyazou » Mon Oct 30, 2017 12:55 pm

logd32 wrote:
Sun Oct 29, 2017 4:04 pm
I have a subsidiary question regarding reset/run after upload, i noticed the board never resets nor run properly after DFU upload, it has to be reset manually.

I have tried to replace systemHardReset(); (after dfuFinishUpload();) by some LED blink and i can see this point is reached, i also tested that systemHardReset(); works fine.
So what could cause the STM32 to halt instead of resetting after DFU_upload? i dont understand he problem.
Thanks
Are you sure that the systemHardReset() will be called after dfuFinishUpload()? Newer Mac OS (El Capitan or later) and libusb may not issue USB bus reset even if you invoke libusb_device_reset(). THe systemHardReset() does not call on my Mac and blupill in fact. Please refer these posts.

[libusb] libusb_reset_device not working on Mac OS X 10.11 El Capitan
https://sourceforge.net/p/libusb/mailma ... /34744234/

OS X El Capitan and its refusal to reset USB devices
https://www.belle-aurore.com/mike/2016/ ... b-devices/

There is some patch which will modify the libusb to call USBDeviceReEnumerate() instead. But the patch seems to be rejected by the community and latest libusb still have the problem.

I've made a patch to the bootloader which will call the systemHardReset() after some timeout to solve this issue. Please see:

https://github.com/hanyazou/STM32duino- ... f39316bbf0

And there is another PR related DFU upload/reset issue below,

https://github.com/rogerclarkmelbourne/ ... 2/pull/297

I'm grad if you try these modification and report the result here (or there) because I REALLY want to solve these upload/reset issue on Mac.

hanyazou
Posts: 43
Joined: Fri May 05, 2017 2:38 am

Re: Booloader/ DFU upload / reset run issues on OSX

Post by hanyazou » Mon Oct 30, 2017 1:00 pm

I can upload blink.ino sketch to STM32 board with my modifications.
You don't have to push the reset button. Please see this video.

https://www.youtube.com/watch?v=b_IgPVzI7hU

logd32
Posts: 8
Joined: Thu Sep 07, 2017 8:41 pm

Re: Booloader/ DFU upload / reset run issues on OSX

Post by logd32 » Mon Oct 30, 2017 7:34 pm

hanyazou wrote:
Mon Oct 30, 2017 12:55 pm
Are you sure that the systemHardReset() will be called after dfuFinishUpload()? Newer Mac OS (El Capitan or later) and libusb may not issue USB bus reset even if you invoke libusb_device_reset(). THe systemHardReset() does not call on my Mac and blupill in fact. Please refer these posts.
Yes, i disabled the nop loop in dfuFinishUpload() and added some LED blink after it is called so i can confirm the LED blinks after upload and reset is issued. i am on 10.11.6 and i can also confirm the reset from host issued by the "upload_reset" does work fine.

I will have a look on your modification and see if it works here, anyway as i told the fix made yesterday works 100%, upload is automatic as it should, the board resets properly after programming and there is no serial port recognition issue, so it is now as reliable as any arduino board at least on OSX1 10.11.6.

logd32
Posts: 8
Joined: Thu Sep 07, 2017 8:41 pm

Re: Booloader/ DFU upload / reset run issues on OSX

Post by logd32 » Mon Oct 30, 2017 7:44 pm

hanyazou wrote:
Mon Oct 30, 2017 12:55 pm
I'm grad if you try these modification and report the result here (or there) because I REALLY want to solve these upload/reset issue on Mac.
Given that the board you make seems pretty large why not using the proper, already proven USB reset circuit directly?
patch on USBDeviceReEnumerate() modifying OSX system is not an option.

logd32
Posts: 8
Joined: Thu Sep 07, 2017 8:41 pm

Re: Booloader/ DFU upload / reset run issues on OSX

Post by logd32 » Mon Oct 30, 2017 7:59 pm

hanyazou wrote:
Mon Oct 30, 2017 1:00 pm
I can upload blink.ino sketch to STM32 board with my modifications.
You don't have to push the reset button. Please see this video.

https://www.youtube.com/watch?v=b_IgPVzI7hU
I just tried your patch, it works for first upload but fails at the next upload.

Post Reply