cancel
Showing results for 
Search instead for 
Did you mean: 

STM32C071 bootloader patterns and boot selector bits defaults

ebastler
Associate II

Hello,

I am currently working on a small device with a C071GBU. This is the first time I am using a chip with shared pins (PA12/PA10 and PA11/PA9) as well as no dedicated single-function BOOT0 pin.

My PCB has very tight space constraints, so software debugger or programming pads are no option - everything must work via the USB port, from first time setup on.

If I understood the specsheet correctly ("Pins PA9 and PA10 can be remapped in place of pins PA11 and PA12 (default mapping), using SYSCFG_CFGR1 register"), PA12/PA11 are default (and not PA10/PA9), so a fresh chip out of the box can be used for USB DFU, am I correct in this assumption?

Then there is my next question - how does BOOT0 work? If I understand correctly, the boot selector bits decide whether PA14 is BOOT0, or whether a software bit is used. The patterns in AN2606 are as follows:

ebastler_0-1736035190580.png

What I do not understand - how are the defaults? As in, if I have a fresh chip directly from the factory, how is it set up? Will PA14 operate as BOOT0 out of the box, or is this something I have to manually set in a first-time-flash? If the flash memory is empty the chip should always default to entering the bootloader, so I can flash a firmware that sets the correct bits through USB, and from there on PA14 is BOOT0, correct? I am sorry for asking questions that may seem trivial - bootloader patterns have been confusing me before, and I would prefer a prototype that works at least well enough to test all important features. This is a personal project, so prototyping funds are limited.

Then I have one third and hopefully last question - If PA14 is set up as BOOT0, can it still be used as a regular GPIO once the chip booted from the program flash memory? Background: The PCB has a single button. If the user holds this button while plugging in the device, it should enter bootloader. Once the chip has booted successfully, this button is however supposed to be used as part of the user interface to interact with the PCB. If the button can work as BOOT0 during startup, and then PA14 as soon as the boot from internal flash is completed, it would simplify my design. My workaround would be to short PA14 to PA13, and use PA13 after startup.

Kind regards,
Moritz

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

> What I do not understand - how are the defaults? 

The reference manual will provide the answers here. It lists "reset" values for registers, and "factory default" settings for option bytes.

PA11/PA12 are used until you remap them. This has to be done after powerup--it is a volatile setting.

TDK_0-1736041844930.png

PA14/BOOT0

 

Default option bytes are nBOOT0 = nBOOT1 = nBOOT_SEL = 1. But since the flash is empty, the USB bootloader will load the first time it's powered (third pattern in the table).

TDK_1-1736042069129.png

 

> If PA14 is set up as BOOT0, can it still be used as a regular GPIO once the chip booted from the program flash memory?

Yes. The only time BOOT0 is sampled is when NRST goes high. Doesn't matter what you do with it after that.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

6 REPLIES 6
TDK
Guru

> What I do not understand - how are the defaults? 

The reference manual will provide the answers here. It lists "reset" values for registers, and "factory default" settings for option bytes.

PA11/PA12 are used until you remap them. This has to be done after powerup--it is a volatile setting.

TDK_0-1736041844930.png

PA14/BOOT0

 

Default option bytes are nBOOT0 = nBOOT1 = nBOOT_SEL = 1. But since the flash is empty, the USB bootloader will load the first time it's powered (third pattern in the table).

TDK_1-1736042069129.png

 

> If PA14 is set up as BOOT0, can it still be used as a regular GPIO once the chip booted from the program flash memory?

Yes. The only time BOOT0 is sampled is when NRST goes high. Doesn't matter what you do with it after that.

If you feel a post has answered your question, please click "Accept as Solution".

First of all - sorry for the late reply. I was busy and had my head elsewhere so forgot to get back at you.

Thank you very much for your help! I overlooked the reference manual when I checked, and thought it might still be unreleased. Now that you told me it exists I went back and found it. You helped me out with all the questions I had.

So summing it up - A11/A12 will be default, and entering USB DFU out of the box is no problem. Then I can set nBoot_Sel to 0 at the first flash, and from that point on pulling boot0 high at boot will enter bootloader, and once the chip boots into program memory PA14 is available as a regular GPIO.

Thank you so much for your help! My project has been proceeding slowly but steadily. I'm excited to see it happen.

Kind regards,
Moritz

Hi Moritz,

I hit then same issue as you, it would have been nice to duplicate some of the info like default pin states.

I have developed a quick board with an STM32C071G8U6N in case you want to compare notes. The board is £47 for 5 off from JLCPCB, I did have to correct quite a few parts including the STM32 which was rotated on the PCB:

https://github.com/htminuslab/STM32C071_Dev_Board

Regards,
Hans.

Hi Hans,

Thanks for your feedback. Seeing a known working implementation of an unknown chip is always reassuring. Looks like my schematic is about right. I noticed this, however - did you swap the labels by mistake, or had to swap them for some reason? Per the datasheet, PA14/pin21 should be BOOT0.

ebastler_0-1739214965496.png

I left nRST/PF2 unconnected, since the chip has an internal pull-up, and I plan on resetting only with a power cycle (hold the BOOT0 button while plugging in).

Hope everything will be fine - having 3 chips I have not previously tested on a single PCB is quite an unnerving experience :D

Regards,
Moritz

Hi Moritz,

Nice catch!

I indeed swapped the wires to make the routing easier but forgot to change the connections. Issues like this reaffirms why design reviews are so important even for a simple circuit as this. Luckily if I had made the board I could simply swap the wires on the pin header as it contains all signals.

Regarding NRST, I believe STM recommends you add a small 0.1uF capacitor to this pin to avoid parasitic resets.

I designed this simple board to get some experience with KiCad8 and JLCPCB, however, it was so easy that I am now working on a larger board which also contains the STM32C071 and a large FPGA. The STM32C071 will take care of the clock, USB, current monitoring and uploading of the bitstream all within a tiny less than £1 QFPN28 package,

Regards,
Hans.

 

Hi Hans,
the switched wires make sense. Yeah, things like these happen, even to the most experienced ones. Part of the reason why we have strict reviews of both schematic and PCBs by at least one other person at work. I sometimes wish I could sneak my personal projects in and know they are good before ordering haha.

True, 100n on nRST would be nicer, but there is just no way for me to squeeze a cap anywhere near the MCU. The internal pull-up will have to suffice. I am already violating courtyards all over this board.

ebastler_0-1739645924287.png

It's a prototype of a pretty niche product - a flashlight controller PCB. 30W boost converter for a LED, 15W USB-C charging/powerbank controller with battery management, and the C071 to control it all on a 20mm PCB where most of the outer rim is reserved for electrically and thermally contacting the flashlight housing. I hope it will end up working as intended.

Kicad is an awesome tool by now - I tried a bunch of software and it still is my favorite. I'm pretty excited for KiCad 9.0 which should launch soon.

Regards,
Moritz