STM32 Design Review

[Stm325]

Hi,

I am using STM32L476RG as a part of my ultrasound project. STM32 basically has the following functions in this system:

1. Send 3 2MHz pulses every 40ms
2. Read 500*2 ADC points using an interleaved ADC triggered simultaneously with pulses
3. Send ADC data through SPI to ESP32

This is my schematic that I will use on my board (The stm32 part of the board, the other parts of the board design is not finished yet)

My firmware code is in the attachments:

I also checked the design self-check guide and everything seemed fine to me. There are some notes in my mind:

1) The board is supplied by a converted 3.3V from 3.7V battery. I am not sure about the affect and placement of the ferrite bead when using a single 3.3V.

2) Is there a need to add diodes if I channel st-link 3.3V to the start of battery 3.3v line. When the stm32 is powered by stlink would that affect the 3.3V line(Because 3.3V also powers the pulser IC on the same board.

3) I am not using any external crystals because the system is already working fine with HSE, so I thought not to ad any external crystals for size optimization.

4) Do I need external crystals for low power modes? The system is working continiously now but I am thinking of adding a low power state for 5 mins.

Other than these I could not think anything else to consider. I would really appreciate it if you can share your thoughts with me.

[Andrew Neil]

Have you studied Application note AN4555, Getting started with STM32L4 Series and STM32L4+ Series hardware development ?

With so many spare pins, make some testpoints for debug purposes; provide access to a UART.

[TDK · Accepted solution]

A ferrite bead connected to the same net on both sides doesn't do anything.

Schematic otherwise looks okay.

You don't need HSE or LSE for low-power modes.

Recommendations:

• Use a standard programmer header that can be connected to an official programmer directly. STLINK-V3MINIE works, as does any other. Programmers generally do not provide power.

[Stm325]

Hi,

Thank you for the answer.

I read the application note, that is where I based my design, I may have some missed points tho.

I will add some debugging pins and uart pads thank you.

[Stm325]

Thank you for the answer.

I accidentaly accepted this as answer but your comment is really helpful.

I realized that if I power it from the same source it wont help but I am not sure what else to do.

Would removing the bead and giving the same 3.3V affet ADC too much.

Or should I divide 3.3V into to lines, use a unity gain buffer and then give it to VDDA maybe?

I thought of using a standard header but I want to minimize the board area. Also, why debugging pins have 3.3V if debuggers cannot power while programming. Should I remove 3.3V debugger pin and continue to power from battery when flashing?

Thank you again

[Andrew Neil]

---

@Stm325 wrote:

I accidentaly accepted this as answer 

---

Instructions to un-mark it here.

---

@Stm325 wrote:

I realized that if I power it from the same source it wont help but I am not sure what else to do.

---

That is shown in the App Note:

So the bead separates VDDA from VDD - it forms a filter between the two.

This is pretty standard - not specific to STM32

eg, https://electronics.stackexchange.com/questions/325810/where-to-put-regulator-when-separating-analog-and-digital-grounds

As well as the schematic, you should also pay attention to layout.

EDIT: added colour

---

@Stm325 wrote:

Would removing the bead and giving the same 3.3V affet ADC too much

---

Depends on how precise you your ADC measurements need to be - only you can say what is "too much" in your particular application

[TDK]

I would use the same net for VDD and VDDA. No ferrite bead.

The ferrite bead will slightly help analog performance, but only if there is sufficient EMC in the frequency range attenuated by the bead. It will not make a huge difference. Read about improving ADC accuracy here:

How to optimize the ADC accuracy in the STM32 MCUs - Application note

The 3V3 pins on the official debuggers are to let the debugger know the voltage on the board. They are inputs to the debugger, not outputs.

Typically, yes, power the board using normal means (in this case, a battery), and connect the programmer to flash.