STM32 first project

[panoss]

In a few days I'm planning to start building a project with STM32F030F4P6. (it 's just an STM32F030F4P6, not a development board)
It 's a starting LED blink project as it 's my first time I 'll try anything with an STM32 MCU.
I want to use the internal oscillator, not any external crystal.
I have installed STM32CubeMX and Atollic TrueSTUDIO.
As a programmer I 'll be using an ST-LINK V2.

I 'm trying to make a step by step tutorial for my self. 

So my first concern is the hardware: I 'm going to make a breakout board and connect it this way with the ST-Link:
ST-LINK.....STM32F030F4P6
RST.........NRST
SWDIO.....SWDIO
SWCLK.....SWCLK
3.3V........VDD
GND........VSS



(the STM32F030F4P6 will be getting powered from the ST-LINK)

Is this the correct way to connect them?

[capt bullshot]

Connect VDDA to VDD also, and don't forget the decoupling caps. I'd recommend a combination of a few 100n ceramic ones and an additional tantalum or electrolytic cap (10uF ... 47uF) in parallel, this helps with ringing on the supply line, especially if you get the supply from that ST-Link clone (or a real one too). Wouldn't matter much if you're just blinking an LED, but you'll probably notice the difference when you start using the ADC.

Read the datasheet to determine if you can leave BOOT0 open or need to add a pull-up or pull-down. The MCU starts an internal bootloader instead of your program if you do that wrong (can't tell this without reading the datasheet, so this is your part). Otherwise looks good.

Edit: The original ST-Link won't supply your board, the 3V3 pin is just a sense input. Don't know if the clone does.

[zzattack]

Always a good idea to also think about your BOOT0 pin and reset circuitry (pullup on nRST).
Personally I also prefer to start out with the 'biggest' version of your pin-compatible microcontroller. During development I hate having to use compiler optimized builds just to fit within flash, with most debugging capability severely hampered.

[MT]

NRST pin should have a 100n cap to DG in either case to prevent spurious resets. NRST pins have inbuilt pullups.

[newbrain]

You have already got a number of good suggestions for the HW.
I would only add to use a ferrite bead from VDD to VDDA and a separate decoupling cap, of you intend to use the ADC.

This application note can also be of some help (see page 23 for a reference design).

I have installed STM32CubeMX and Atollic TrueSTUDIO.

As ATollic True Studio is no longer developed, you could install STM32CubeIDE, i.e. the integrated sum of Atollic TS and CubeMX.

Going the vendor IDE way is a path of minimal resistence, but, as my doctor says I'm allergic to Eclipse, I'll also suggest another alternative, possibly as a later step.
You can generate a Makefile from CubeMX, then use whatever IDE/Advanced editor (Sublime/Atom/VS Code) you fancy - expect doing some homework to have a functioning compile/flash/debug, though.
A number of other options exist, of course.

[panoss]

What do you think of this?



SWD_CON is a connector where the ST-Link will be connected.
ST-Link 's 3.3V will not be connected.

The MCU will be powered by a 3V3 power supply.
I have added decoupling caps to VDD and VDDA.
The RESET button just shorts the NRST to GND.
Boot0 connects through two jumbers either to 3V3 or to GND.

I have only omited the ferrite bead from VDD to VDDA because ferrite beads I 've seen are bulky, too big in size.

[SiliconWizard]

Looks OK to me.

[newbrain]

Looks fine to me too.
FB can be found in SMD from 0402 upwards, so not really that big...but you should be OK without it.

[SiliconWizard]

I like the Laird ferrite beads.
https://www.laird.com/emc-components/ferrite-chip-beads/chip-beads-signal-filtering

[panoss]

If I replace the two electrolytics (C2 & C5) with SMD ceramics of the same capacity, will there be any problem?

you could install STM32CubeIDE, i.e. the integrated sum of Atollic TS and CubeMX

STM32CubeIDE is only for 64bit machines, as far as I can tell...
I 'm using a 32 bit Win 7 machine for MCU programming, so I guess I 'll have to go back to STM32CubeMX and Atollic TrueSTUDIO, right?

[jhpadjustable]

You shouldn't have used electrolytics in the first place. From the datasheet, section 6.1.6, "Power supply scheme":

Each power supply pair (V DD /V SS , V DDA /V SSA etc.) must be decoupled with filtering ceramic
capacitors as shown above. These capacitors must be placed as close as possible to, or
below, the appropriate pins on the underside of the PCB to ensure the good functionality of
the device.

Everything else looks alright to me.

[SiliconWizard]

The ceramic caps (even though they are not explicitely marked as ceramic, we can assume they are) are all there in the OP's schematic.

[jhpadjustable]

(even though they are not explicitely marked as ceramic, we can assume they are)

Not if OP's asking.

If I replace the two electrolytics (C2 & C5) with SMD ceramics of the same capacity, will there be any problem?

[Kleinstein]

For C2 and C5 it helps to have capacitors with some ESR. So ceramic are not as good as electrolytic ones in this case. A ceramic cap with some 1-10 Ohms in series would be a better substitute for an electrolytic cap.   
With decoupling also the layout can have quite some effect. Digital circuits are often quite robust and may work even if large mistakes in the decoupling are made - however with a poor layout or wrong caps chances are higher it may fail or produce EMI.

If one has not ferrite bead or other separation one may not need both C2 and C5, as they are in parallel.

[SiliconWizard]

(even though they are not explicitely marked as ceramic, we can assume they are)

Not if OP's asking.

If I replace the two electrolytics (C2 & C5) with SMD ceramics of the same capacity, will there be any problem?

Well. Dunno if we talk about the same thing, or understand each other.

The OP has put ceramic caps (100n, 10n) for decoupling, we can assume he's going to put them close to the IC. This is just what ST suggests. The reason is they have very low ESR and behave reasonably well at high frequencies, so they are better than electrolytic caps for just that.

I admit the OP's schematic is a bit ambiguous though, as the electrolytic caps are drawn closer to the IC - he should move the ceramic bypass caps closer to the MCU to make it clearer, although it's not strictly required (some people even put their bypass caps separately in their schematics, I don't like it, but hey...)

There's no problem adding larger caps, on top of that, as electrolytic or tantalum caps, though. But yes, you'd typically place them further away. So I guess our misunderstanding comes more from the "drawing" style than from the schematic content itself, which to me was correct. Then the question would have been the layout. But maybe you were able to "read" from the OP's posts and drawing style that he was going to get the layout wrong.

For simplication, for VDDA, I would personally just replace C4 and C5 with just ONE 10µF ceramic cap (this is what I usually do). Of course as close to the MCU as possible. As for C2, it's probably useless here, but it won't hurt. Just place it closer to the power supply connector than to the MCU.

As there is only one VDD pin, I would also get rid of one of the 100nF caps. Only one is enough.

[MT]

If I replace the two electrolytics (C2 & C5) with SMD ceramics of the same capacity, will there be any problem?

you could install STM32CubeIDE, i.e. the integrated sum of Atollic TS and CubeMX

STM32CubeIDE is only for 64bit machines, as far as I can tell...
I 'm using a 32 bit Win 7 machine for MCU programming, so I guess I 'll have to go back to STM32CubeMX and Atollic TrueSTUDIO, right?

Win32bit Attolic 9.3 are still available , F030 are supported from 9.0 version.
https://atollic.com/resources/download/windows/windows-archive/?submissionGuid=7b9dd1fb-0c42-4cd4-aa4b-bbf08d1eb48f

[thm_w]

Edit: The original ST-Link won't supply your board, the 3V3 pin is just a sense input. Don't know if the clone does.

Clone stlink outputs 3.3V so its is OK to power the circuit.
5V output is also available (direct from USB).

[jhpadjustable]

Well. Dunno if we talk about the same thing, or understand each other.

The OP has put ceramic caps (100n, 10n) for decoupling, we can assume he's going to put them close to the IC. This is just what ST suggests. The reason is they have very low ESR and behave reasonably well at high frequencies, so they are better than electrolytic caps for just that.

I read those five caps in panoss's schematic as a straightforward copy of the datasheet recommendation, due to their values, the 10µF being an order larger than recommended but not completely out of line. Aside, on STM32 devices with more than 3 VDD/VSS pairs, the designer is cautioned to place the larger per-rail (not per-pin-pair) cap, here 4.7µF, nearest a particular VDD/VSS pin pair, which leads me to believe the larger caps are meant for the whole device, not as a recommendation for the whole system. Excessive in the present case? Probably, but ceramic chip caps are sooo cheap these days.

Not to hijack, but under what sort of circumstances would you choose not to merge the two VDDA caps?

As there is only one VDD pin, I would also get rid of one of the 100nF caps. Only one is enough.

Agreed. ST's recommendation hints, but doesn't explicitly state, 100nF per VDD/VSS pin pair is only necessary on pin pairs that are actually pinned out.

[DBecker]

You might take all of these recommendations with a grain of salt.

Most of the external parts are not absolutely required.  You want them in a commercial product that needs to work in a wide range of circumstances and pass noise emissions tests.  But for a hobby project where you are hand soldering each part you can skip all of them and things will still work.

Specifically you don't need external components on the reset pin in most circumstances.  The STM32 has sophisticated internal circuits to handle power on reset and brown-out shutdown.  I've seen old-fashioned designs that use a capacitor and resistor to generate a power-on reset.  This can actually defeat the reliable internal circuit.  Using just a capacitor is less likely to cause a problem, but it's only necessary if the reset circuit has a long wire likely to pick up lots of noise.  The STM32 isn't going to reset from noise with nothing connected to the pin.

For the power supply decoupling capacitors you can get away with using far less than the full set, especially if you are not simultaneously switching the output drivers into their maximum load.  The core runs off of a internal regulator that is typically 1.2V (lower for more modern cores).  Your main supply has to dip close to that before you'll impact operation.  Sure, you won't be delighted with the ADC performance, but you aren't going to be getting representative results with a hand-wired prototype anyway.

[techman-001]

You might take all of these recommendations with a grain of salt. Most of the external parts are not absolutely required.

That's right, attached is a pic of my hand soldered, standalone, STM32F051 one external component ( a cap across the 3.3 supply) module.

I flashed it using the internal serial bootloader. It runs Forth internally using 3.3v power from a typical USB/3.3v serial dongle.

[panoss]

I followed your suggestions and changed a few things:
-I put the ceramic cap (100n) for decoupling close to the IC, as closer as I could.(in the layout)
-I  replaced the electrolytics with ceramics.
-I replaced C4 and C5 with just ONE 10µF ceramic (I just removed C4), and in the layout I put it as close to the MCU as possible.
-C2 removed.
-One of the 100n caps (C3) was removed.



Any further suggestion would be welcome.

[capt bullshot]

I think you've got all that ceramic / electrolytic discussion wrong - There's nothing wrong with the ceramic caps, but if you use them alone you may run into supply voltage ringing issues. You should add some damping here, one (quite classical and simple) method would be to use an electrolytic or tantalum instead of the larger ceramic cap. Another method would be to add some resistance to the larger ceramic (put a 1R ... 2R2 resistor in series with it). As long as you don't use the ADC, you most probably won't notice the difference.

Others are right too, you don't need a capacitor tied to the NRST pin. Having a onboard LED is a good measure, it could also be useful to fan out "standard" UART pins to a 3pin header for "printf debugging" purposes.

[panoss]

So, if I put a 1 Ohm resistor in series with C5 and remove C6 I 'll be ok?

[newbrain]

Others are right too, you don't need a capacitor tied to the NRST pin.

I disagree, for two reasons:

• There's a reset button, in this case the cap is explicitly recommended in both the reference manual and the hardware app note.
• At least one other very experienced member of this forum has had some issues when omitting the cap (though on other STM32 series, IIRC).

Having a onboard LED is a good measure, it could also be useful to fan out "standard" UART pins to a 3pin header for "printf debugging" purposes.

A very good suggestion!

So, if I put a 1 Ohm resistor in series with C5 and remove C6 I 'll be ok?

I would not remove C6, as stated above.
The stability of the supply vs. ESR of the decoupling caps depends on many factors (specific regulator/LDO, cable length etc.) - you could experiment a bit.

[panoss]

Ok, C6 stays.

it could also be useful to fan out "standard" UART pins to a 3pin header for "printf debugging" purposes.

If I understand correctly you mean a Serial port that I could use the way it 's used in Arduino?
Yes I 'd like to have the possibility to Serial.print(something).
I think it 's necessary.
How can I do this?
Should I change something in the circuit to achieve this?

[SiliconWizard]

Just break out ALL IO pins to a connector, then you'll get a full dev board for very little additional work (not a lot of pins here).

[panoss]

I will break out all pins anyway in two pin headers.
But how about the serial port?
Is it the serial wire debug (SWD), that is SWDIO and SWCLK?

[newbrain]

I will break out all pins anyway in two pin headers.
But how about the serial port?
Is it the serial wire debug (SWD), that is SWDIO and SWCLK?

No, that's the debug port!

If you are breaking out all pins, you are all set. USART1 (the only one for a 030 in TSSOP20 package) will be on pins 8 (PA2, TX) and 9 (PA3, RX).

EtA: if you feel lost in ST documentation, some hints on its structure are here

[panoss]

USART1 (the only one for a 030 in TSSOP20 package) will be on pins 8 (PA2, TX) and 9 (PA3, RX).

And where should I connect the TX and RX?
(for Arduino I use an FTDI232)

EtA: if you feel lost in ST documentation

'Lost' can only partially describe the feeling! Thanks!

[newbrain]

And where should I connect the TX and RX?
(for Arduino I use an FTDI232)

You can use your FTDI232 USB-serial adapter.
If the UART side is 3.3 V, PA2 and PA3 are fine, instead if it's 5 V you must use the alternate PA9 and PA10 for USAT, as they are 5 V tolerant pins.
The levels are largely compatible.

This kind of information is in the datasheet document, specifically, Table 11 and Table 12 of the latest version.
TTa pins are 3.3 V tolerant, with analog connection to the ADC. FT pins are 5 V tolerant: be careful, not to fry your little chip!

[panoss]

Ok, I think I finished with hardware. Let 's go to software now.
I use STM32CubeMX & Atollic TrueSTUDIO 9.3.0.

STM32CubeMX:
- New Project->Start My Project from MCU->ACCESS TO MCU SELECTOR
- From the list I select STM32F030F4Px
- The picture of the MCU appears.
- I click on pin PA0 and a list apears. From the list I choose 'GPIO_Output'. The PA0 pin now becomes green.

I click on the tab 'Clock Configuration'...
What should I select (or enter) here?
Let me remind you I 'll be using the internal oscillator.

[capt bullshot]

With my version of CubeMX, the default is 8MHz CPU clock derived from the internal oscillator. ATM I'm using an older version of CubeMX, this might have changed with the latest version. Anyway, for a first blinky demo on bare metal, this is sufficient. If there's an implausible configuration, some red fields would appear.
To switch to higher speeds, change "System Clock Mux" to "PLLCLK", and set "*PLLMul" to "X 12", this should result in 48 MHz clock.

Go to "Generate Code", select your correct Toolchain / IDE, then generate Code, open the project in your IDE, have fun

[panoss]

Wait a minute, this is the configuration:



How will I know if the internal oscillator is selected? (and not some external)

[capt bullshot]

You know this because the System Clock Mux is set to "HSI" (high speed internal oscillator).
HSE (high speed external) is disabled anyway, since you didn't activate the respective pins in the pinout view (look for "RCC"), so Cube wouldn't let you select the external clock here.

[thm_w]

Yeah, would be nice if they had info on that page, but at some point you have to expect certain knowledge from the designer.

LSI RC = low speed internal resistor capacitor oscillator
HSI = as mentioned

[panoss]

Ok, Clock Mux is set to "HSI"-> high speed internal oscillator is selected.
How about speed?
How do I know which speed is selected?

Is it SYSCLK 8MHz?

[capt bullshot]

You know this from reading the datasheet. Somewhere within the datasheet the frequency (and deviation to expect) of all the internal oscillators is mentioned. Anyway, it's written all over the place in the diagram you posted - just for your convenience.

There's a difference between arduino and bare metal microcontroller, and this involves a steep learning curve that includes thoroughly reading the vendor supplied documentation.

[panoss]

From what I understand (the datasheet seems really hard and huuuudge to me) HCLK is the main CPU clock.
So when I see the above diagram I conclude: it 's configured to run with the internal clock at 8MHz.
Right?

[newbrain]

I see you got it! 

I will nonetheless post my answer.

Is it SYSCLK 8MHz?

CLock chains of modern MCU are quite complex (and this one is a very simple example!), so as capt bullshot says it's be good to read the DS.
After all, you have selected a relatively unsophisticated MCU, a reasonable choice if you are a beginner, and the documentation will not be overwhelming.
With more powerful ones you can find yourself wading through more than 2500 pages...

That said, the diagram in CubeMX is almost an exact copy of what you find in the relevant DS chapter, and conveys most of the needed information.

The 2nd item from top on the right side says "HCLK to AHB bus, core, ..." so HCLK is the one you are looking for.
You can write your chosen value in the HCLK box, and let CubeMX work out how to obtain it (it will warn you if it cannot find a solution).

[panoss]

Ok, I 'll leave it as is, 8MHz is just fine for me.

I go to the next tab, 'Project Manager'.
Project Name...ok...Project Location...ok...Application Structure->'Basic'...ToolChain Folder Location...ok...
ToolChain/IDE->TrueSTUDIO???
(I 'll be using Atollic TrueSTUDIO).

With more powerful ones you can find yourself wading through more than 2500 pages...

Holly S$it!!

[techman-001]

Ok, I 'll leave it as is, 8MHz is just fine for me.

I go to the next tab, 'Project Manager'.
Project Name...ok...Project Location...ok...Application Structure->'Basic'...ToolChain Folder Location...ok...
ToolChain/IDE->TrueSTUDIO???
(I 'll be using Atollic TrueSTUDIO).

With more powerful ones you can find yourself wading through more than 2500 pages...

Holly S$it!!

The STM32F030 is a fairly small Cortex-M0, with only the following internals to learn 
      31 peripherals
     353 registers
    2564 bitfields

However it's modern and fast, and you won't have to go thru "Blue Pill" GPIO hell.

[panoss]

 
 



Ok, I selected 'TrueSTUDIO'.
Switched to tab 'Tools', I change nothing here.
I click 'Generate Code', a bit later a message shows up saying the 'Code is Successfully Generated under...etc...etc'..
I click 'Open Project' and Atollic TrueSTUDIO starts and, I suppose, this is my project.
Have I done it correctly or maybe missed something?

[iMo]

The simplest way to start with stm32 is the BluePill with stm32duino (arduino compatible).
I can recommend.

PS: the stm32duino site has been closed recently, the successor with guys/girls who will certainly help you is:
https://mcu.selfip.com

[panoss]

My first thought was STM32duino but then I thought I should do it 'the way...real men do it'...

I suppose it has some advantages (I 'm not sure it really has, I just suppose) using Atollic over STM32duino.

[iMo]

The advantage I see it is arduino compatible, you may run it withing Arduino IDE, or Eclipse based IDEs like Sloeber.
The stm32duino was based on leaflabs core, now they starting to use HAL based one, supported somehow by STM.
Again, it is arduino compatible, therefore you get 99.9% of the existing arduino libs available such it compiles straight (and the megatons of arduino libraries are the key point why we mess with arduino actually).

[capt bullshot]

My first thought was STM32duino but then I thought I should do it 'the way...real men do it'...

Yes, that make the difference. With arduino someone else has done all the low level stuff, read the MCUs user manual and datasheet, made some fundamental design decisions etc. and provided you with a rather simple IDE and a lot of libraries that do all the basic stuff for you, just take an example and modify.

Now you're free to do all this on your own, you'll even have a hard time to figure out how to set the GPIO pins from your code and how make an appropriate delay to be able to see your LED blink.
Cube and Atollic provides you with all the necessary stuff to achieve this in more than one way (e.g. using library functions, C macros or bare metal), but gives you little hints about the names of the functions / macros to use, and how to use them. You're expected to have decent C (not C++ alike as in arduino) programming knowledge / experience, know about debugging techniques (same thing again, to get "printf debugging", it's up to you to decide which way to go to achieve this and to figure out how to to) and so on.

Yes, that's the way real men are supposed to program an MCU Arduino is a toy for kids

[newbrain]

My first thought was STM32duino but then I thought I should do it 'the way...real men do it'...

I suppose it has some advantages (I 'm not sure it really has, I just suppose) using Atollic over STM32duino.

I think you have taken a worthy road. Not an easy one, and more challenges await you.
You are doing fine, and you can always ask for help here: most members are willing to contribute suggestions, with no newbie shaming.

Going the "just another HW under Arduino abstraction" way won't let you learn as much.

Of course IMHO, YMMV...

the megatons of arduino libraries are the key [...] mess.

[panoss]

Also with STM32duino (I think) I can 't program an STM32F030F4P6, but only the Blue Pill.

[iMo]

Sure, it depends on the OP's motivation. To be able to wire something together around an stm32 and write a working code during a Saturday's evening (where you will utilize a dozen of ready made libraries), or to become an expert for STM32 HAL is, of course, a different stuff..

[iMo]

Also with STM32duino (I think) I can 't program an STM32F030F4P6, but only the Blue Pill.

For your "first stm32 project" I would certainly not choose an stm32something where I have to mess with register's and datasheets. I would invest $3 for 2 BluePills (there are many other boards compatible afaik), and $2 into the stlink usb programmer dongle. That is all. And if happy with my new toy and hobby, after some time I would go into something more demanding.
But sure, YMMV..

[panoss]

I have a problem.
In the project created and, then, opened with Atollic, and without making any modification at all, I click Project->Build All.
And I get a bunch of errors!!
In 'Problems' tab: Errors(100 of 550 items)

[newbrain]

I have a problem.
In the project created and, then, opened with Atollic, and without making any modification at all, I click Project->Build All.
And I get a bunch of errors!!
In 'Problems' tab: Errors(100 of 550 items)

So many errors usually mean that something really fundamental is missing/wrong.
The first thing that comes to mind are the HAL: which code generation option did you select in CubeMX? include all, include needed or link?
Include all is probably the safest (at the price of a lot of unused source code that will be compiled and discarded in the linking phase).
Another possible issue might be spaces in some of the path names: sometimes they cause problems (due to bad quoting/escaping)-

Post a sample of the error list (possibly text from the console output, not a screen capture of the error tab) and we'll see (though I won't have much more time today and ~0 tomorrow...).

[panoss]

Ok, I deleted the project and recreated it (with STM32CubeMX) and now builds fine without errors.
I have no idea why...

In STM32CubeMX I have selected 'Copy only the necessary files'.
(Code Generator->STM32Cube Firmware Library Package->Copy only the necessary files)


And now, to the point blink an LED:

Code: [Select]

/* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */


    /* USER CODE BEGIN 3 */

// Blinking an LED at pin PA0 (Pin 6)
HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_6);
HAL_Delay(1000);

  }
  /* USER CODE END 3 */


Is my code correct?

[newbrain]

Ok, I deleted the project and recreated it (with STM32CubeMX) and now builds fine without errors.

I would have advised to try it, but I undersatand you don't yet have the HW, so...
There are two problems in the code:

• The GPIO_PIN_x macros refer to the GPIO pin name, not the physical package pin number, so it should be...exercise left for the reader 
• This is not a problem with the code, rather with the way to use CubeMX: if your code is not inside a /* USER CODE BEGIN xxx */.../* USER CODE END xxx */ bracket, it will not be preserved if you re-generate the code from CubeMX.
  So, move it a bit up or down or you'll lose it if e.g. you add the UART or another GPIO pin...

[panoss]

Code: [Select]

HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_0);

Is it ok now?

(I have moved the code after '/* USER CODE BEGIN 3 */')

[TomS_]

Any further suggestion would be welcome.

This thread feels a lot like "design by committee", and I know you said you were done with the hardware, but here are my (hardware related) suggestions.

1. Try not to have ground symbols pointing upwards. Traditionally that is where your positive supply symbols would be placed/face, and at a glance could cause some confusion.
2. You dont have to explicitly show your capacitors wired directly next to their respective pins in the schematic, its quite common to set them aside somewhere, and can help keep certain areas of your schematic around the MCU clearer, and may prevent #1.
3. Your nRST pin is floating if you disconnect your programmer. Probably you want to pull that signal up via a resistor.
4. Is R1 connected to JP1 and JP2 correctly? It looks like youve run the net to the wrong side of those jumper symbols. If you intend to keep that jumper configuration, probably you dont need R1 at all.
5. You could simplify your BOOT0 circuit - determine whether the signal should ordinarily be high or low and tie it to that supply via a resistor, then use a single jumper to "pull it the other way". Have the jumper in when you need to modify the BOOT0 signal, and leave it out for normal operation kind of thing.

[newbrain]

3. Your nRST pin is floating if you disconnect your programmer. Probably you want to pull that signal up via a resistor.

It will not be floating.
It has an internal pull-up and an active POR/PDR  circuitry.

Not even the ST provided Nucleo and DISCO boards have a pull-up, and it's not there in the reference schematic.

The cap is an extra precaution, especially since there's a button (and provided in all ST boards and reference schematic).

EtA: @Panoss yup! looks fine.

[panoss]

4. Is R1 connected to JP1 and JP2 correctly? It looks like youve run the net to the wrong side of those jumper symbols. If you intend to keep that jumper configuration, probably you dont need R1 at all.

I just copied the app note, page 23. They do have a resistor connected to Boot0 pin.
The only difference is that in the place of the switch I put 2 jumbers.




I suppose you mean I should do it like this(ok, I will):

[TomS_]

They do have a resistor connected to Boot0 pin.
The only difference is that in the place of the switch I put 2 jumbers.

Sure, I understand why you have two headers, although looking at the app note, option 0 (no jumper) would not be valid as the pin would be floating. The signal needs to be either high or low.

Hence my suggestion was to do the BOOT0 signal as follows:



With no jumper, the signal is pulled low which causes the chip to boot from internal flash. If you place the jumper in you get a high signal. And no chance of leaving the pin floating which could cause erratic behavior and ruin your day.

Resistors on inputs are not strictly necessary for a simple dev board, probably more application specific. e.g. If there is a chance of large current spikes making it into a pin that would exceed its maximum rating, then you should definitely add them. That said, for a hobbyist, they could still be useful for protecting against accidental shorts.

I suppose you mean I should do it like this(ok, I will):

Yes that is better. My only concern with the original drawing is whether the net from R1 was actually connected to the jumpers since they were drawn to the opposite side of the symbol, which could mean come time to do the board layout those connections might be missed.

Anyway, that was my input, dont want to cause too much more noise now. 

[panoss]

No 'noise' at all, your remarks (as everybody else 's) are welcome. (and very useful)

[teksturi]

1. Try not to have ground symbols pointing upwards. Traditionally that is where your positive supply symbols would be placed/face, and at a glance could cause some confusion.

2. You dont have to explicitly show your capacitors wired directly next to their respective pins in the schematic, its quite common to set them aside somewhere, and can help keep certain areas of your schematic around the MCU clearer, and may prevent #1.

Actually it is really good happit to but them directly next to their respective pins in the schematic. Then you really can see that every needed pin has needed capacitor(s). Also when you layout your pcb you will see right away what capacitor you have to but next to te pin. I have always hate when capacitors are but aside somewhere else. To prevent #1 there are many other things to do also.

[TomS_]

Actually it is really good happit to but them directly next to their respective pins in the schematic. Then you really can see that every needed pin has needed capacitor(s). Also when you layout your pcb you will see right away what capacitor you have to but next to te pin. I have always hate when capacitors are but aside somewhere else. To prevent #1 there are many other things to do also.

Well, there are multiple ways to achieve the same end goal.

If you have a large device with many power supply pins (e.g FPGA), placing all caps next to the device on the schematic is going to be a challenge, and Im yet to see that done.

Decoupling caps, except in cases where they may have specific properties*, are probably generic enough throughout the design and dont need to be placed next to any component in particular - they all go between power rails.

* e.g. different types, capacitances, dielectrics, maybe power rails - in which case there are ways to differentiate, like differing number ranges for their identifiers, or you can annotate the schematic

I have always hate when capacitors are but aside somewhere else.

House rules, or personal preferences I suppose.

[MT]

This thread feels a lot like "design by committee", and I know you said you were done with the hardware, but here are my (hardware related) suggestions.
3. Your nRST pin is floating if you disconnect your programmer. Probably you want to pull that signal up via a resistor.

Welcome to the committee!