[SOLVED] Bootloader for a mini-PLC with STM32F103VE w/ 16MHz crystal

My actual “project” is, to modify/enable a mini-PLC (DIN rail / “smart-relay”),
so that it can be used by everybody with the Arduino-IDE/STM32duino via USB.
(as mentioned already in my “say hello” – Thread)

This mini-PLC (commercial product / already on the market) uses the STM32F103VET6 (512kB Flash /64kB RAM / 100pin).

The manufacturer is very interested and cooperative and will send me a sample device to evaluate if this device could be used with Arduino/STM32duino, but until now they did not sent me a complete schematic

what I found out up to now is:
– there is a kind of SWD connector on the mainboard
– there is no reset-button or any jumper
– there is a 1.5k pullup from USB D+ to 3.3V
– there is a “ID_USB”-pin used on Port PA15 (connected to the 5V of the USB-plug via a resistor divider)
– the Boot0- and Boot1-Pin are pulled down to GND
– there are 2 LEDs connected from 3.3V via resistor to the Ports PC8 and PC9

so as a real noob,
I believe that as a first step I have to compile the STM32duino-bootloader
with parameters that fit my “board”, right ?

so, can I omit the complete “BUTTON” and the “USB-DISC” -stuff ? (since I have no “Maple hardware” ?)
and just write:
#define HAS_MAPLE_HARDWARE 0
#define LED_BANK GPIOC
#define LED_PIN 9
#define LED_ON_STATE 0
#define USER_CODE_RAM ((u32)0x20000C00)
#define RAM_END ((u32)0x20005000)

If you have a SWD connector, you don’t necessarily need a bootloader.
You can use a STLink probe to upload new sw and to debug as well.

just for explanation:
I am not the “end user” of this PLC.
The SWD-connector is inside the device (inside the enclosure), I can use it,
but the “end users” should use the USB interface that is located “outside” accessible on the front panel (and no additional hardware needed).

I just edited my first post to make that a little bit clearer:My actual “project” is, to modify/enable a mini-PLC (DIN rail / “smart-relay”),
so that it can be used by everybody with the Arduino-IDE/STM32duino.

OK.
Then I will move this thread to the bootloader section.
(and changed the title to reflect the intended scope.)

Maybe this post is interesting for you: http://stm32duino.com/viewtopic.php?f=32&t=508

Then I will move this thread to the bootloader section.
(and changed the title to reflect the intended scope.)
hmmm… OK,
but this is just the first question of many following questions regarding this project I think …

however, I will just create new threads then ..

beside my other questions above:
in the readme of the repo is written “…Use GCC 4.8 (not 4.9 or newer,.. “
is this still valid ?

please, can someone answer this ?
is it really necessary to downgrade my arm-none-eabi-gcc to 4.8 ?
it’s a really very very old version (https://developer.arm.com/open-source/g … /downloads)
I try to build the bootloader on linux how can I “downgrade” to arm-none-eabi-gcc to 4.8, if necessary ?

in the meantime I found this announcement
http://stm32duino.com/viewtopic.php?f=16&t=1538
(so the statement “…Use GCC 4.8 (not 4.9 or newer,.. “ is not valid anymore)

so I suggest it would be better to change the readme of the repo not to confuse beginners like me …

b.t.w.
another statement in the readme regarding the buttonsNote. Most “generic” STM32F103 boards only have a reset button, and not a user / test button. So the bootloader code always configures the Button input pin as PullDown, hence if a button is not present on the Button pin (Default is PC14), the pin should remain in a LOW state, and the bootloader will assume that the Button is not being pressed.

IMPORTANT. If you have a board where you have external hardware attached to pin PC12 which will pull this pin HIGH, you will need to make a new build target for you board which uses a different pin for the Button, or completely modify the code so that the Button is ignored.leaves me completely at a loss (the text is confusing).
I don’t understand that:
– what buttons are you talking about the reset- or the user button ?
– in the code I can not see any reference to PC12 – so it is unclear what is really meant here ?
– so if I omit the complete BUTTON_BANK GPIOB -stuff neither PC14 nor PC12 is ‘touched’ (e.g. configred as pulldown) by the bootloader-code ?
(–> see my similar question in the first post on this thread)

I’ll answer multiple things at once:
-You can install the bootloader and use the usb for uploads. All that’s needed in the 1k5 pull up resistor and you confirmed it’s there. We use a trick to pull the USB line and then let if float up again to cause a re-enumeration.

-There are precompiled bootloaders in Roger’s repo. You can download one of those:
https://github.com/rogerclarkmelbourne/ … y_binaries
The pin in the name means where a status led is connected (i.e. generic_boot20_pb12.bin is compiled for using PB12 for a status led). Make sure you pick one that either matches that led output, or at least doesn’t comflict your that line being an input in your schematic that may cause a short and kill the pin, since the bootloader is going to pull that pin high and low to blink the status led.
The bootloader is compatible with any F103 MCU, it detects how much flash is available and the page size.
About the button, is a user button, not the reset button. The original Maple boards had a pushbutton, if pressed while the board is rebooted, the bootloader will stay running and not jump to the user sketch until either a sketch is uploaded, or the board is reset again with the user button not pressed. That mode was called perpetual bootloader mode.
If that pin in your schematic is pulled to the level in which the bootloader would think the button is pressed, then each time the board is rebooted the bootloader would stay in perpetual bootloader mode and not jump to the user sketch.
If that’s the case, then define the button port and pin to something that either has a button attached, or is not pulled to the active level for the button input. I don’t remember off the top of my head, but I think it may be possible to change which level is active in one of the #defines in the code, then you cn recompile it.

UPDATED: removed some information since you have found it already.

thanks for lots of infos,
but again my question
so, can I omit the complete “BUTTON” and the “USB-DISC” -stuff ? (from the #defines)

another point:
do I have to define the crystal frequency if it is different from the default 8MHz ?
I can see that this is done here for a 12MHz crystal –> https://github.com/rogerclarkmelbourne/ … are.c#L118
my crystal frequency is 16MHz
do I have to add another (different) PLL setup sequence then in “hardware.c” ?

[BlackBrix – Tue Dec 26, 2017 4:47 pm] – my crystal frequency is 16MHz
do I have to add another (different) PLL setup sequence then in “hardware.c” ?

would it be OK to write it like this (for 16MHz HSE) ?
/* Configure PLL */
#if defined XTAL16M
// 16 MHz crystal (using the Bit 17 PLLXTPRE=1 => HSE clock divided by 2 before PLL entry)
SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) | 0x001F0400); /* pll=72Mhz(x9/2),APB1=36Mhz,AHB=72Mhz */
#elif defined XTAL12M
// 12 MHz crystal
SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) | 0x00110400); /* pll=72Mhz(x6),APB1=36Mhz,AHB=72Mhz */
#else
// 8 MHz crystal default
SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) | 0x001D0400); /* pll=72Mhz(x9),APB1=36Mhz,AHB=72Mhz */
#endif

if i had do this, i’d fire up cubemx, setup for the chip and set the crystal, generate as little code as possible.
examining the setup code should give you the info required,
of course some translation may well be required
srp

[BlackBrix – Wed Dec 27, 2017 4:42 pm] –

[BlackBrix – Tue Dec 26, 2017 4:47 pm] – my crystal frequency is 16MHz
do I have to add another (different) PLL setup sequence then in “hardware.c” ?

would it be OK to write it like this (for 16MHz HSE) ?
/* Configure PLL */
#if defined XTAL16M
// 16 MHz crystal (using the Bit 17 PLLXTPRE=1 => HSE clock divided by 2 before PLL entry)
SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) | 0x001F0400); /* pll=72Mhz(x9/2),APB1=36Mhz,AHB=72Mhz */
#elif defined XTAL12M
// 12 MHz crystal
SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) | 0x00110400); /* pll=72Mhz(x6),APB1=36Mhz,AHB=72Mhz */
#else
// 8 MHz crystal default
SET_REG(RCC_CFGR, GET_REG(RCC_CFGR) | 0x001D0400); /* pll=72Mhz(x9),APB1=36Mhz,AHB=72Mhz */
#endif