Linux: flashing own STM32F103C8T6 generic USB bootloader not much luck

STM32duino bootloader aka Maple bootloader
User avatar
Pito
Posts: 1391
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Linux: flashing own STM32F103C8T6 generic USB bootloader not much luck

Post by Pito » Sun Apr 30, 2017 12:26 am

There is a binary for bootloader with 12MHz Xtal - try it
#elif defined TARGET_STBEE
https://github.com/rogerclarkmelbourne/ ... 1/binaries
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1483
Joined: Mon Apr 27, 2015 12:12 pm

Re: Linux: flashing own STM32F103C8T6 generic USB bootloader not much luck

Post by victor_pv » Sun Apr 30, 2017 3:49 am

Hypercube wrote:
victor_pv wrote: If you select STLink as upload method then the Serial device is the USART1, not the USB.
Try loading the bootloader to the board, then upload using bootloader method, otherwise try SerialUSB.begin, SerialUSB.print etc.
I think today STLink upload sets the serial device to USB by default and that bit is now working.

The problems were down to Arduino IDE grabbing the serial port and not letting it go when the device disconnects (Ubuntu 14.04).
What the serial monitor needs is a restart, disconnect and connect button at the bottom of the window with a option to set the relevant port.
If I close serial monitor, unplug the device, connect it back in and open serial monitor, the thing is OK, but hey
I don't want to keep doing this wearing out the connector.

The other half of the problem is that I have a 12MHz xtal on my board. Which means the default 8MHz clock tree settings for the maple board won't work in this new board until BOARD_RCC_PLLMUL is set correctly everywhere. And then the boot loader needs to be compiled - don't know how to do that :(

As a shortcut I tried to run maple_mini_bootloaer_updater.ino but after you press Y, the USB will not work because of the clock tree settings
being incorrect again somewhere.
That's right, the bootloader will need the PLL multiplier adjusted too and then recompiled. You will need the compiler, which you already have as part of arduino, in one of it's folders, and the make tool, which I believe was not part of Arduino. I don't remember where did I download it from, I think may have been as part of avr-gcc.

Hypercube
Posts: 6
Joined: Fri Apr 28, 2017 10:28 pm

Re: Linux: flashing own STM32F103C8T6 generic USB bootloader not much luck

Post by Hypercube » Sun Apr 30, 2017 4:40 pm

Pito wrote:There is a binary for bootloader with 12MHz Xtal - try it
#elif defined TARGET_STBEE
https://github.com/rogerclarkmelbourne/ ... 1/binaries
Hi Pito, that was very handy and it worked.
After flashing bootloader I tried to program a sketch using upload method set to STM32duino bootloader.
The Arduino IDE then complained then dfu-util could not work.
Searching around it was 64 bit and the 32 bit I was running my Ubuntu 14.04 on.
So rebuilt it using the instructions here:
http://www.stm32duino.com/viewtopic.php ... t=10#p4549
It turns that had some problems - build_dfu-util.sh had a syntax error.
sudo apt-get install build-essentials should read sudo apt-get install build-essential
for my system.

Anyway generated the dfutils, moved the old ones to a separate directory and put in the new ones.
And that workd with the stbee image built with 12MHz.

On booting up the board through USB, I could upload a sketch with upload method set to STM32duino bootloader.
But after that I could not program it with another sketch.
Putting CPU into DFU mode by setting Boot0 to High, and pressing reset did not work.
Even STLink became unresponsive.
But then I managed to get STLink to work again by putting CPU into DFU mode and then programming using STLink.
I programmed the board a couple more times with stbee image, and tried to upload a sketch.
Always the first time is OK but second time onwards not OK.
Its as if the CPU could not be booted back into same mode like it gets to after it is flashed with the binary bootloader if something like blinky was programmed once by the Arduino IDE.
:
Wading through the bootloader code I can see #ifdef XTAL12M is where it gets its speed set up ( in hardware.c )
Then I checked the USB enumeration code and its different to what I was expecting.
The code I thought would be yanking PB9 to get the PC to re-enumerate the USB but instead its
now turning the USB peripheral on the chip on and off presumably for the same effect - though I can't see
how it implements all the details - I assume it done through call back functions.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests