recompiling bootloader for 16Mhz external clock

STM32duino bootloader aka Maple bootloader
Post Reply
oribotic
Posts: 5
Joined: Mon Jun 01, 2020 6:19 am
Answers: 1

recompiling bootloader for 16Mhz external clock

Post by oribotic »

Hello!

I'm working on a custom board, one of my first after playing around with the same chip on a bluepill. The MCU is a STM32F103C8, it has LED on pin 13 and basically the same idea a a blue pill except instead of an 8Mhz crystal, I've got a 16Mhz crystal on the board. I think the next revision will go back to an 8Mhz crystal, but I'm here now, so trying to solve it.

The problem is that the board keeps booting into bootloader mode, after writing and testing sketches.

I took the following steps to get this far:

the standard bootloader is for an 8Mhz external crystal, so the bootloader needs to be configured for a 16Mhz crystal. This seems to be easy enough, by defining XTAL16M in config.h:

just find the target and add XTAL16M flag

Code: Select all

...
#elif defined TARGET_GENERIC_F103_PC13
...
#define XTAL16M
I then built and tested two versions of arm-none-eabi-gcc 4.8 as recommended:

on debian:
arm-none-eabi-gcc version 4.8.4 20141219 (release) (4.8.4-1+11-1)

on macos:
arm-none-eabi-gcc version 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322] (GNU Tools for ARM Embedded Processors)

I flashed the bootloader using an ST-LINK V2 dongle, boot0 set high, and reset.

in one terminal I run:

Code: Select all

st-util
this starts talking to the st-link dongle

and in another I run:

Code: Select all

st-flash write generic_boot20_pc13.bin 0x08000000


which then give this output of the flashing:

Code: Select all

st-flash 1.6.0
2020-05-31T16:36:37 INFO common.c: Loading device parameters....
2020-05-31T16:36:37 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-05-31T16:36:37 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2020-05-31T16:36:37 INFO common.c: Attempting to write 7160 (0x1bf8) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08001800 erased
2020-05-31T16:36:37 INFO common.c: Finished erasing 7 pages of 1024 (0x400) bytes
2020-05-31T16:36:37 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-31T16:36:37 INFO flash_loader.c: Successfully loaded flash loader in sram
  7/7 pages written
So the bootloader for a 16MHz external crystal is flashed.

Then, I needed to let arduino know about the 16M crystal and so I've modified the STM32duino board variant for my board generic_stm32f103c:

adding this to the top of board.h

Code: Select all

#define XTAL16M 
then in boards.cpp

Code: Select all

static void setup_clocks(void) {
 ...
 ...
#ifdef XTAL16M
    // 16MHz crystal (HSE)  
    // in this case we additionally set the Bit 17 (PLLXTPRE=1)  =>  then HSE clock is divided by 2 before PLL entry
    RCC_BASE->CFGR |= RCC_CFGR_PLLXTPRE;
#endif
...
...
this tells arduino IDE about the 16mhz crystal.

After all that, arduino IDE can flash sketches, using STM32duino bootloader as the upload method, arduino happily flashes my sketches, the usb serial appears, I can test my sketches and all appears to be working super fine, except after RESET the board only boots into bootloader mode, with PC13 flashing.

flashing sketches looks as follows:

Code: Select all

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device

Download	[                         ]   0%            0 bytes
Download	[=                        ]   5%         1024 bytes
Download	[==                       ]  11%         2048 bytes
Download	[====                     ]  16%         3072 bytes
Download	[=====                    ]  22%         4096 bytes
Download	[=======                  ]  28%         5120 bytes
Download	[========                 ]  33%         6144 bytes
Download	[=========                ]  39%         7168 bytes
Download	[===========              ]  45%         8192 bytes
Download	[============             ]  50%         9216 bytes
Download	[==============           ]  56%        10240 bytes
Download	[===============          ]  61%        11264 bytes
Download	[================         ]  67%        12288 bytes
Download	[==================       ]  73%        13312 bytes
Download	[===================      ]  78%        14336 bytes
Download	[=====================    ]  84%        15360 bytes
Download	[======================   ]  90%        16384 bytes
Download	[=======================  ]  95%        17148 bytes
Download	[=========================] 100%        17148 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Waiting for /dev/cu.usbmodem14201 serial...Done
does anyone have any suggestions as to why the board might be booting back into bootloader mode (short period of fast flashing then to slower flashing of PC13 LED), it doesn't appear to recognise that there is a sketch programmed.

thanks!
by oribotic » Mon Jun 01, 2020 10:09 am
ok, solved it

I didnt have a boot1 breakout on my board, didn't think it was necessary...
It turns out the bootloader looks at PB2 (aka boot1) and it must have been floating, not pulled low.
but I did have PB4 next to a ground pin, so when that's configured as the buttonpin and tied to ground, it works as expected.

The bootloader lets you define any pin you like as the BUTTON_PIN

here's my complete section in config.h of the STM32duino-bootloader

Code: Select all

#elif defined TARGET_GENERIC_F103_PC13

    #define LED_BANK            GPIOC
    #define LED_PIN             13
    #define LED_ON_STATE        0

// Use Boot1 PB2 as the button, as hardly anyone uses this pin as GPIO
// Need to set the button input mode to just CR_INPUT and not CR_INPUT_PU_PD because the external pullup on the jumplink is very weak
    #define BUTTON_INPUT_MODE 	CR_INPUT
    #define BUTTON_BANK GPIOB
    #define BUTTON_PIN 4
    #define BUTTON_PRESSED_STATE 1
// added for oribokit
    #define XTAL16M
it now works super with 16M external clock and behaviour is as expected.
hope my description above helps someone along the way!
Go to full post

oribotic
Posts: 5
Joined: Mon Jun 01, 2020 6:19 am
Answers: 1

Re: recompiling bootloader for 16Mhz external clock

Post by oribotic »

ok, solved it

I didnt have a boot1 breakout on my board, didn't think it was necessary...
It turns out the bootloader looks at PB2 (aka boot1) and it must have been floating, not pulled low.
but I did have PB4 next to a ground pin, so when that's configured as the buttonpin and tied to ground, it works as expected.

The bootloader lets you define any pin you like as the BUTTON_PIN

here's my complete section in config.h of the STM32duino-bootloader

Code: Select all

#elif defined TARGET_GENERIC_F103_PC13

    #define LED_BANK            GPIOC
    #define LED_PIN             13
    #define LED_ON_STATE        0

// Use Boot1 PB2 as the button, as hardly anyone uses this pin as GPIO
// Need to set the button input mode to just CR_INPUT and not CR_INPUT_PU_PD because the external pullup on the jumplink is very weak
    #define BUTTON_INPUT_MODE 	CR_INPUT
    #define BUTTON_BANK GPIOB
    #define BUTTON_PIN 4
    #define BUTTON_PRESSED_STATE 1
// added for oribokit
    #define XTAL16M
it now works super with 16M external clock and behaviour is as expected.
hope my description above helps someone along the way!

Post Reply

Return to “USB bootloader”