search

stm32duino / Arduino_Core_STM32

STM32 core support for Arduino
https://github.com/stm32duino/Arduino_Core_STM32/wiki
Other
2.83k stars 973 forks source link

USB Bootloader not recognized after upload a sketch #735

Closed khyarul closed 5 years ago

khyarul commented 5 years ago

After upload a sketch using usb bootloader:

  1. Maple mini bootloader 2.0
  2. USB HID bootloader

My maple mini doesn't recognized by my computer until I flashed the new bootloader And it happens every time after I uploaded a sketch

stas2z commented 5 years ago

have you enabled USB support in menu?

khyarul commented 5 years ago

yes, I've enabled U(S)ART support & USB support...

After several times trial I can get the HID bootloader still working even it doesn't recognized as HID bootloader again, but it showed as "STM SERIAL" com port at "Device Manager" and I must press the reset button or unplug the power at least 3 seconds before run it again. So I can upload other sketch again.

But no luck when I try the same method on maple mini bootloader 2.0

khyarul commented 5 years ago

After fresh flash of HID bootloader 2.2.2 & before uploading the first sketch

image

after that my computer can't recognize the HID device, so I press and hold the reset button about 3s, luckily it shows as "STM SERIAL" and the serial monitor is working too...

image image

However it still weird for me...

stas2z commented 5 years ago

if you can see STM Serial (0483:5740) it means your new compiled sketch uploaded, started and init USB CDC

khyarul commented 5 years ago

yes, but the HID bootloader doesn't recognized as HID DEVICE anymore although it shown as STM SERIAL com... With the same method on maple mini bootloader 2.0, my computer totally doesn't recognized the device

stas2z commented 5 years ago

ANY bootloader starts only for a short moment and jump to main code after for hid bootloader it starts as a bootloader only if boot1 pulled high for maple bootloader it blinks a few secs

so after flashing yr sketch youll never see devices as a bootloader without special movements (changing boot pins state)

for maple bootloader, if you are using original one (not a rogers fork), try to use maple dfu original option

fpistm commented 5 years ago

Hi @khyarul This is normal you don't see HID BL or DFU after a flash. The application is started properly then you have the STM32 Serial VCP. When you upload again the the board will switch automatically in BL mode to allow flash and then start your application.

joej970 commented 5 years ago

Hi, I have a simillar issue. I am using medium desnsity BluePill STM32F103C8 and HID bootloader 2.2. When I upload a simple (blink) sketch, everything works well. The BluePill is detected as USB Serial device COM5 in Device manager, even after several uploads. But as soon as I upload a code Basic.ino from MPU-9250 DMP Arduino library, booloader breaks and Windows does not detect it anymore properly -> DevMngr: Unknown USB device (Device decriptor request failed). The library is written for Arduino SAMD boards, which AFAIK use same Cortex M3 processor as BluePill, so I guess the library should work on BluePill as well. But ok, I will write my own library.

But what I would like to know is how can a specific code break bootloader and furthermore what bootloader do you suggest to use with STM32F1? (my needs: Serial monitor & reliable)

fpistm commented 5 years ago

Hi @joej970 Sorry, I don't know why. I do not suggest any bootloader as I'm not maintain them.

joej970 commented 5 years ago

@fpistm Thanks for reply. I think the reason for crashing the bootloader is the library's code which was not meant for STM32. But it happens with both bootloaders: HID 2.2 and Maple DFU 2.0 so I guess it is not the BL's fault. Anyways, what is then the purpose of mantaining STM32 cores if you cannot provide/suggest a working bootloader? I do not blame you - I believe you are still doing a great job. But your hard work in core development is no use for community if there is no reliable way to upload and test the code. IMO the compiler should not compile a code (as in my example) that can potentially break the bootloader.

uzi18 commented 5 years ago

nothing special here: https://github.com/sparkfun/SparkFun_MPU-9250-DMP_Arduino_Library/blob/f46b97c4dff33c83eebc775a7fce5b70df071984/src/util/arduino_mpu9250_i2c.cpp#L22-L49

Basic demo uses SerialUSB, maybe you can disable/comment all DMP library usues so you will know if problem is with serialUSB or lib?

fpistm commented 5 years ago

Anyways, what is then the purpose of mantaining STM32 cores if you cannot provide/suggest a working bootloader?

They are several way to upload the core. If you want use a bootloader this is your choice. Use the STM32 built in one in that case. I could not maintain all third party libraries, bootloaders, code,... available. This core is open source and all contribution are welcome. That's why it offers possibility to use those bootloaders. Maybe issue is in the core but as this is only met with this third party library, I guess this is linked to it and I can't debug all of them.

joej970 commented 5 years ago

I think newbies would start using STM32 Cores easier and faster if there was one reliable, officially supported upload method preferrably with bootloader because it takes least additional wiring. But I totally understand that all this is unmanageable for one developer and I still pay respect to you for developing all that open source code. Anyways I found a fix for crashing bootloader. It happened because STM32 started to initialise MPU-9250 too fast - probably before code was uploaded completely. Adding 5s delay() before calling imu.begin() seems to fix a problem. Anyone has an idea why would STM32 start a program before being totally set up and able to succesfully run code?

KJansun commented 4 years ago

the HID and DFU versions i tried crashes a lot. It would be great to not use that jumper, but only use the usb!