I’m coming from Arduino world. I bought a Maple Mini clone (for $4) and a noname “STM32F103C8T6 ARM STM32 Minimum System Development Board Module Forarduino” with PCB of the same shape as the Maple Mini (for $3.75) – actually here’s the photo: http://www.rogerclark.net/stm32f103-and … 1-5-x-ide/
I’d like to ask you a couple of questions that would help me jump into this ARM world world faster:
– the noname STM32F103C8T6 board got two yellow jumpers. What do they do? Don’t you happen to have a schematics of the board, please?
– I managed to flash the “generic_boot20_pc13.bin” to the noname board and it’s now working nicely and DFU is faster than on the maple mini. Is it a good idea to flash the maple mini with a new bootloader (“maple_mini_boot20.bin”) as well? It could release 3 kB of RAM and some flash space, I’ve read.
– which one of these two boards is “better”? The maple has twice the flash but is missing the 32 kHz oscillator, right?
– what is those four header pins on the side of the noname board good for? They’re marked GND, VCC, DIO and CLK.
– I plan on making a wrist watch with this STM32. The goal is thus to minimize the number of components. Do you think it’s a good idea to run without external crystals/oscillators? Will the internal 8 MHz and 40 kHz ones be sufficient? I know USB will not work without external 8 MHz but I can live with that. Any idea if the RTC will be OK (and accurate) with the internal 40 kHz?
– programming in Linux: are there good reasons for NOT using the Arduino IDE 1.6.x with STM32 support? Are there any good libraries? I suppose there’s a gcc for arm in stock Ubuntu/Debian so the compiler would not be an issue. Doesn’t the Arduino way add too much overhead? I’ve noticed that pure Blink example is almost 20 kB of binary. Is it OK? What kind of code is there included by default?
– in the latest STM32 support for Arduino IDE I can’t find “upload into RAM” that used to be in the original hacked Arduino 1.5.x for Maple. Can’t the RAM option be added back? Or is it better to always upload to the flash? It’s got only 10 thousand rewrites until it wears out, is it enough when one starts to learn ARM coding? 
– RTOS: do you use any “realtime OS” or at least a library that would allow for running concurrent tasks without spending unnecessary time in delays()?
OK, I’ve got couple more questions regarding the level of HW support (displays, ethernet cards etc) but I’ll leave it for later.
Thank you in advance for your answers, tips and help.
here some quick infos:
your “noname board” is well known in this forum: use the search function for “blue pill” and/or “red pill” (insider knowlege 
)
Flash size of the STM32F103C8T6: If you have luck, you have the same flash size than on mini (there is a thread about the “hidden” flash memory, other user please help out with the link)
bootloader for mini: Yes, I see only advantages installing the new bootloader (a little bit more ram/flash, faster while upload…). Be sure to have a serial USB-converter or a ST-Link V2, so you can heal a broken mini.
maple vs blue pill: meanwhile there is no big difference since we have the universal bootloader (maple mini has a slight different HW layout for USB/bootloader)
GND, VCC, DIO and CLK: sounds like the st-link upload pins. (didn’t have one)
wrist watch: the internal timing is bad, REAL bad, even with 8MHZ, so a add. 32khz would be necessary.
upload to ram: was deleted by Roger a few months ago. Search for threads. Conclusio: total waste of time on a small STM32F1xx, even a simple blink wouldn’t fit into RAM
RTOS: use RTOS There is a build in timer library: see -> http://leaflabs.com/docs/timers.html —> hardware timer
OK, I’ve got couple more questions regarding the level of HW support (displays, ethernet cards etc)
Please use the search function before posting or read the library section first (we have some good libraries for ILI9341, ILI9163C, OLED’s (SSD1306), the rusty Nokia 5510,…)
I've noticed that pure Blink example is almost 20 kB of binary
I’m coming from Arduino world. I bought a Maple Mini clone (for $4) and a noname “STM32F103C8T6 ARM STM32 Minimum System Development Board Module Forarduino” with PCB of the same shape as the Maple Mini (for $3.75) – actually here’s the photo: http://www.rogerclark.net/stm32f103-and … 1-5-x-ide/
I’d like to ask you a couple of questions that would help me jump into this ARM world world faster:
– the noname STM32F103C8T6 board got two yellow jumpers. What do they do? Don’t you happen to have a schematics of the board, please?
– I managed to flash the “generic_boot20_pc13.bin” to the noname board and it’s now working nicely and DFU is faster than on the maple mini. Is it a good idea to flash the maple mini with a new bootloader (“maple_mini_boot20.bin”) as well? It could release 3 kB of RAM and some flash space, I’ve read.
– which one of these two boards is “better”? The maple has twice the flash but is missing the 32 kHz oscillator, right?
– what is those four header pins on the side of the noname board good for? They’re marked GND, VCC, DIO and CLK.
– I plan on making a wrist watch with this STM32. The goal is thus to minimize the number of components. Do you think it’s a good idea to run without external crystals/oscillators? Will the internal 8 MHz and 40 kHz ones be sufficient? I know USB will not work without external 8 MHz but I can live with that. Any idea if the RTC will be OK (and accurate) with the internal 40 kHz?
– programming in Linux: are there good reasons for NOT using the Arduino IDE 1.6.x with STM32 support? Are there any good libraries? I suppose there’s a gcc for arm in stock Ubuntu/Debian so the compiler would not be an issue. Doesn’t the Arduino way add too much overhead? I’ve noticed that pure Blink example is almost 20 kB of binary. Is it OK? What kind of code is there included by default?
– in the latest STM32 support for Arduino IDE I can’t find “upload into RAM” that used to be in the original hacked Arduino 1.5.x for Maple. Can’t the RAM option be added back? Or is it better to always upload to the flash? It’s got only 10 thousand rewrites until it wears out, is it enough when one starts to learn ARM coding?
– RTOS: do you use any “realtime OS” or at least a library that would allow for running concurrent tasks without spending unnecessary time in delays()?
OK, I’ve got couple more questions regarding the level of HW support (displays, ethernet cards etc) but I’ll leave it for later.
Thank you in advance for your answers, tips and help.
I’ve been reading forum in the meantime and found out that the blue pill’s yellow jumpers are BOOT0 (the upper) and BOOT1 (the lower) (in Roger’s video). Will check the microcontroller pinout if it helps me to figure out what the BOOTx is good for.
I also found the information about removing support for uploading code into RAM for those 20 kB STM32F1x.
The Roger’s video also mentioned the ST Link pins on the header. Not sure what that is good for, maybe debugging, dunno. Will find out.
I’m still interested if there are any good reasons for programming the boards outside of Arduino IDE, just with gcc and make. With the AVRs you don’t really need any initial code, the CPU is ready to run instantly after power up. With ARM it might be far more complicated to set the hardware up to a reasonable state so that GPIO, I2C, SPI, DMA, timers and interrupts work, no idea.
EDIT: thanks, victor_pv. I’ve seen the thread about rotating cubes. Will give it a try once I attach one of my LCDs.
ST Link is a hardware device… USB on one side, and pin connections on the other. You would use this to upload code if you do not wish to use the bootloader. Of course, you then get the benefit of the additional (small) flash that exists where the bootloader would have been located.
I’m still interested if there are any good reasons for programming the boards outside of Arduino IDE, just with gcc and make. With the AVRs you don’t really need any initial code, the CPU is ready to run instantly after power up. With ARM it might be far more complicated to set the hardware up to a reasonable state so that GPIO, I2C, SPI, DMA, timers and interrupts work, no idea.
… if you program outside the Arduino IDE (This Forum is titled Arduino for STM32), but just want to use a makefile, I think one of the threads addressed that. https://github.com/sudar/Arduino-Makefile
But you can build arduino with make and do the same things that are done in the IDE. Now, if you go off and write assembler… you must provide everything.
I know you are enthusiastic, but you simply must start using the forum Search as Google indexes this full site. When you have a technical question or when you hit a brick wall, we can be here to help. Do not get all clammy: I tell every newbie here the same thing! 
Ray
Jump links on Boot0 and Boot1. They control whether the internal Hardware Serial bootloader in the chip, is run after reset. This is nothing to do with our bootloader its a feature of the chip. Boot0 high enables the bootloader, and Boot1 controls some options to do with the internal bootloader.
Its all documented by STM.
Ray has already mentioned the other 4 pins. They are ARM SWD connections, which you can upload via an SWD programmer like Black Magic Probe, STLink or other programmers.
This allows in circuit debugging, however at the moment only the command line GDB (GNU Debugger) works for all platforms. Linux users can use the Eclipse CDT Standalone Debugger, or possibly DDD, however we do not have an easy setup for in circuit debugging at the moment.
Re: RAM uploads by the bootloader
I took the decision to remove this as its generally useless, because only sketches like blink fit into RAM. I even went back to the old Maple IDE and tried with the old bootloader to see which original LeafLabs examples would upload to RAM and as far as i could tell, it was only Blink that would fit.
Additionally, because the way the bootloader has to reset itself after upload, there were issues about reliably determining whether there was a sketch in RAM that the bootloader should run, and i experienced a lot of false positives in my testing.
If you really want upload to RAM, feel free to modify the bootloader code. most of the RAM code is just commented out, but I’d recommend you go back and look at the initial commit to the github repo of the new bootloader, as I doubt just uncommenting things to do with the RAM upload will now make it work again.
But you really will be wasting your time, unless you have some special small program you need to upload more than 10,000 times.
BTW. 10,000 is the minimum guaranteed number of uploads to the chip. In reality is suspect the number is much much higher.
Additionally, because the way the bootloader has to reset itself after upload
No.
The board should get reset via the IDE
Depending when you downloaded the repo and what OS you are running on, you may need to download a newer version
Basically the board sketch has some code in the background waiting for a special reset sequence to be sent via serial usb. On windows this is done in the jar file, however I don’t have the source for the jar so I had to write separate upload-reset utilities for OSX and Linux (which I did about 2 weeks ago)
If your serial port is selected correctly in the IDE the board should reset its self prior to upload.
Enable verbose for uploads in the preferences and look at the messages
Re: Uploading via Ethernet etc
You could probably get a device like an ESP8266 to do this, in fact I think there is a project for ESP8266 that may already do this
Just using Bluetooth serial would be problematic, as you’d need to find a way of setting boot0 from the external device.
I guess you could do some sort of hack, like attach a capactor via a diode to a GPIO to Boot0, then in the sketch pull boot0 high via GPIO then reset the cpu, and as long as the RC constant was correct on the cap / resistor on Boot0 it would hold Boot0 high for long enough to reset the board and enter its hardware bootloader.
Ethernet uploads would need a completely different bootloader that could communicate via ethernet etc.
I’ve not seen an ethernet bootloader to Maple boards. But you could search for “STM32F103 ethernet bootloader” in case someone has already written one
Don’t search for “STM32 ethernet bootloader” as some processors have onboard ethernet hence you’ll get a load of useless results as the F103 doesnt have onboard ethernet.
Personally I’d go for the ESP8266 option.
https://youtu.be/cvKC-4tCRgw
Ray
Very interesting.
I didn’t realise that was possible.
Edit.
This is the code that currently does the reset into the bootloader
It doesn’t look like it changes any off the PLL settings, so I suspect some different code would need to be used to enter the hardware bootloader
// Got the magic sequence -> reset, presumably into the bootloader.
// Return address is wait_reset, but we must set the thumb bit.
uintptr_t target = (uintptr_t)wait_reset | 0x1;
asm volatile("mov r0, %[stack_top] \n\t" // Reset stack
"mov sp, r0 \n\t"
"mov r0, #1 \n\t"
"mov r1, %[target_addr] \n\t"
"mov r2, %[cpsr] \n\t"
"push {r2} \n\t" // Fake xPSR
"push {r1} \n\t" // PC target addr
"push {r0} \n\t" // Fake LR
"push {r0} \n\t" // Fake R12
"push {r0} \n\t" // Fake R3
"push {r0} \n\t" // Fake R2
"push {r0} \n\t" // Fake R1
"push {r0} \n\t" // Fake R0
"mov lr, %[exc_return] \n\t"
"bx lr"
:
: [stack_top] "r" (STACK_TOP),
[target_addr] "r" (target),
[exc_return] "r" (EXC_RETURN),
[cpsr] "r" (DEFAULT_CPSR)
: "r0", "r1", "r2");
Very interesting.
I didn’t realise that was possible.
Edit.
<…>
It doesn’t look like it changes any off the PLL settings, so I suspect some different code would need to be used to enter the hardware bootloader
<…>
Edit.
Looks like there is code here
https://my.st.com/public/STe2ecommuniti … views=5344
And there are various other bits of code scattered around the web that describe how to do this
<….>
Looks like there is code here
https://my.st.com/public/STe2ecommuniti … views=5344
And there are various other bits of code scattered around the web that describe how to do this
No worries
I’ll leave it for the OP to use the code to do this and report back.
No.
The board should get reset via the IDE
Basically the board sketch has some code in the background waiting for a special reset sequence to be sent via serial usb. On windows this is done in the jar file, however I don’t have the source for the jar so I had to write separate upload-reset utilities for OSX and Linux (which I did about 2 weeks ago)
If your serial port is selected correctly in the IDE the board should reset its self prior to upload.
Enable verbose for uploads in the preferences and look at the messages
Clearly you have your own ideas regarding the STM32F1xx bootloader for Ethernet uploads; based upon your success with the 8-bit AVR family in the Arduino line. That’s great, but… I’m having a very difficult time following your posts because the theme of each is scattered with needs: in the initial post you discuss the STM32F1xx use in a timepiece, then a bit later you are wanting to use an Ethernet shield to flash the user application in another STM32 board.
As you are obviously experienced and technically competent, you may find the link below to an application note by STM of some interest. The uC being targeted in the note is a more advanced controller than the STM32F103; that is, the STM32F107 has built-in MAC. Abstracting the thought process to using an external Ethernet controller may however assist you and shed some insight into how to morph the existing bootloaders to work with an external Ethernet “shield.”
http://www.st.com/st-web-ui/static/acti … 275365.pdf
Unless your post has stirred the appetite of some of the others in our group, I suspect however that you are pretty much on your own in the coding of the new bootloader. In fact, you may be the group’s residing expert on Ethernet bootloading as you have AVR experience. This is a rather interesting project and I think maybe even most useful, but I have not found any pertinent literature directly related to the STM32F103 controller.
Best of luck,
Ray
I’m having a very difficult time following your posts because the theme of each is scattered with needs: in the initial post you discuss the STM32F1xx use in a timepiece, then a bit later you are wanting to use an Ethernet shield to flash the user application in another STM32 board.
<…>
That’s OK. I’ve been given lost of useful pointers in this thread so I can start. Thank you all.
BTW, the bluetooth bootloader would be used for the wrist watch, so I could update the firmware without attaching any cables
Petr
Actually, this is not my idea. This is how an OTA update is implemented in AVR over 2.4 GHz wireless.
If you happened to hear about a bootloader modification for stm32duino that would be doing this please let me know.
To do OTA, I suspect you best approach would be to build it into the bootloader.
You can use the NVRAM to pass a command / flag to the bootloader, and there is already partial support for this.
The bootloader would end up being larger, but if you can keep the size below 0x5000, you can use the existing setting in the IDE which supports the old (larger) bootloader
Like I said, although you need to reset the processor to enter the bootloader, the data in the NVRAM addresses get retained.
So you must put a magic number for your load from OTA into NVRAM, get the code to reset into the bootloader as normal.
The bootloader checks the NVRAM, and if it finds the OTA command, it doesnt init the USB and DFU etc, it calls your new OTA via SPI function, which reads in the data from your external memory ( or whatever…)
one of the rather fun possibility is that you have a ‘sketch’ that does that OTA, this sketch is *shrewd* in that it is divided into 2 big parts, the first part is simply to start at the normal entry point(0x8002000 (stm32duino bootloader) or 0x8005000 (maple bootloader)), then it ‘reserve’ all that space and say jump to another location say e.g. 0x8018000 96k into the flash and run the OTA code there. this would need some manipulation with the ld (‘scatter loading’) scripts to make such an image
the OTA code can then ‘download’ the image and write it back at 0x8002000 in that 96k block that you ‘reserved’ earlier, assuming that u’ve got 128k flash on it 
The downloading of the update bin file is going to be far more work than flashing it.
There are various strategies about which chuck of code does the downloading, and it depends if you want to have the ability to update the downloader and bootloader code, what you end up doing
Including the downloader as part of the sketch is probably the easiest to write, as you can make use of the SPI and other libs, and write to external flash
Then reboot using the NVRAM (Its actually called a BPK register i think), to use the external flash data to flash the sketch
Also, this is totally universal approach since it’s up to the user and their sketch how they get a new firmware stored in the external flash – if via wired or wireless connection or by any other way. The bootloader just checks if there’s a new version and doesn’t care where it came from and how.
BTW, now when we have Roger’s attention – have you noticed the HID USB improvement in another thread? viewtopic.php?f=13&t=576 Will you include it in the main repo?
the usb hid updates would need various tests to see that it is after all working ok, the use of composite devices can lead to various compatibility surprises.
in addition to that, a hid device can say function as a *mouse*, it can directly ‘interfere’ with desktop operation if it is programmed to do so, making the use of the real mouse difficult / impossible.
but the main thing would be the composite devices which may require some ‘special’ support on the desktop (windows, linux, etc side), the standard drivers may not work, this require testing
Also, this is totally universal approach since it’s up to the user and their sketch how they get a new firmware stored in the external flash – if via wired or wireless connection or by any other way. The bootloader just checks if there’s a new version and doesn’t care where it came from and how.
BTW, now when we have Roger’s attention – have you noticed the HID USB improvement in another thread? viewtopic.php?f=13&t=576 Will you include it in the main repo?
viewtopic.php?f=13&t=576&start=120#p28041
I was asking if you’d include “libarra”‘s improvements in your USB HID branch (it’s actually called addMidiHID, if I am not mistaken).
Just making sure you’ve noticed that he seems to solved the composite issue. Frankly, I don’t know where “his repo” is so I haven’t checked myself. I just thought it would be a pity if some progress with USB on STM32 got “lost”.
The only information i didn t see here (that solved my problem of reset during the upload under ubuntu) was to increment the reset time
“${DIR}/upload-reset” ${dummy_port_fullpath} 1500
viewtopic.php?f=13&t=576&start=120#p28041
I was asking if you’d include “libarra”‘s improvements in your USB HID branch (it’s actually called addMidiHID, if I am not mistaken).
The name of this thread is at least confusing.
Regarding the SPI for loading the update, I would take the software SPI version instead of the HW SPI, because it would fit into less code space. And the bit-banding can also be done pretty fast using direct register accesses.
![[Pending Enhancement] RTC values resetting](https://sparklogic.ru/wp-content/uploads/2019/11/nucleo-l476rg-zestaw-startowy-z-mikrokontrolerem-z-rodziny-stm32-stm32l476-90x90.jpg)
