I want to design my own STM32-based device, but I'm running into lots of issues

[SparkyTD]

Hi there,

I am pretty much a beginner when it comes to PCB design, but I would like to challenge myself by designing a custom STM32 based board that I will be using for my project. I have looked at many schematics for similar devices, mostly the Arduino Mega and Arduino Due, and I feel like I understand most things, and I would be comfortable giving it a go with my own custom schematic and PCB design. However, my biggest issue has been chip selection. I have a set of requirements for my project, and I need an STM32 that meets all of them. The problem is, that since I don't have the equipment or skill to solder such tiny SMD components, especially if I end up choosing a BGA chip, I will have to use an SMT service like JLCPCB to have my PCB manufactured, and the SMD components attached.

This means that I have to adjust my project to JLCPCB's stock availability, which changes daily, and by the looks of it, they don't have any powerful STM32s in stock. It would also be helpful if a development board would be available for the chip that I choose, so I can experiment on it, and learn the basics of the programming before I start designing my own PCB. This reduces the number of available parts even further.

Before I go further, here are the hard requirements of my project:

• At least 2 separate, user-accessible SPI interfaces
• Support for a microSD card reader
• Support for a WiFi module like the EMW3081
• 300kB+ SRAM (512 would be better, but I could probably make it work with 300+)
• 2-4MB Flash

I find it very difficult to find a chip that meets these requirements, and is in stock at JLCPCB. As a beginner, I don't think I should try doing stuff like external memory chips, because I'm not comfortable with more than 2 layers of PCB, and I have no idea how to do all the trace-length matching, etc...

Can anyone give me some advice on how to get started with this project? Or should I just give up and design the whole thing around a Raspberry Pi Zero W?

[vad]

Consider using external SPI or QSPI flash chip. As for the availability, Mouser has few STM32 models in QFN package in stock now. Otherwise back order parts now and be prepared to wait 52 weeks or so. If you need just several MCUs for prototyping or personal project, desoldering can also be an option.

[lucazader]

Due to the chip shortage right now its going to be very hard to nail down a chip months in advance from a supplier like JLCPCB.
Some PCB manufacturer and assembly places do allow you supply some parts (eg the hard to find MCU) yourself. And then they will source the rest (eg resistors etc).
At my company this is how we have been doing recent prototypes, via PCBway.

As far as selecting the correct chip:
For the RAM requirements you probably need to look at something in the F7 H7 or G4 range of microcontrollers from ST.
For Flash space. There are parts that do come in up to 2MB, however this is the largest that ST go to as far as built in flash.
If you need more than this, you will likely have to go with external QSPI flash, which as you have said is not really something that a beginner should really look to doing.

One thing you could look at doing is getting a pre made higher end MCU module that include most of what you need, and then making a carrier board for it.
You could look at getting a Teensy 4.x
Or something like the arduino pro portentia H7 lite connected
The portentia would work with the arm mbed platform so lots of good drivers out there for doing what you might need. It also include BLE and WiFi and a few other nice things.

[SparkyTD]

I've never heard of the Arduino Pro, but it seems like one of the coolest boards I've seen in a while, thank you for recommending it!

As for the PCB manufacturing, if I could get my hands on a chip from mouser/digikey/etc within reasonable time, do you think JLCPCB would accept it as a user supplied part? Or if not, could you recommend any other PCB manufacturers that do?

[vad]

For the RAM requirements you probably need to look at something in the F7 H7 or G4 range of microcontrollers from ST.

Also L4 and L4+

[vad]

As for the PCB manufacturing, if I could get my hands on a chip from mouser/digikey/etc within reasonable time, do you think JLCPCB would accept it as a user supplied part?

JLCPCB will not do that. Direct quote: “ Currently the components supplied by customer are not accepted by JLCPCB SMT. We provide parts you will need to have your PCB assembled. Please note components that are not in our library won’t be placed on your board.”

Why not learn soldering QFP or even QFN yourself?

[SparkyTD]

Why not learn soldering QFP or even QFN yourself?

I'm still just getting started with THT soldering, so I wouldn't trust myself with smaller SMD components, especially if it's a somewhat expensive MCU. Plus I would have to make an investment by buying a hot plate, a hot air station, and maybe even a new soldering station because my current one is very dodgy. I'm trying to keep the cost of this whole project as low as possible.

[vad]

QFP can be soldered with soldering iron.

[I wanted a rude username]

How core is the STM32 requirement for you? If you can compromise on that, JLCPCB carry a range of modules with Wi-Fi and up to 16 MiB of flash and 8 MiB of PSRAM: the ESP32. It's somewhat easier to get into than STM32 as well, and the price is right. The tradeoff is that if energy consumption is a concern, you need to carefully manage its various sleep modes.

[SparkyTD]

How core is the STM32 requirement for you? If you can compromise on that, JLCPCB carry a range of modules with Wi-Fi and up to 16 MiB of flash and 8 MiB of PSRAM: the ESP32. It's somewhat easier to get into than STM32 as well, and the price is right. The tradeoff is that if energy consumption is a concern, you need to carefully manage its various sleep modes.

The project that I'm working on is a "smart" electricity meter, and the current working prototype is actually based on the ESP32. The problem was that I had three SPI devices that I wanted to attach to the chip (A TFT display, a microSD card reader and an external ADC chip), but unfortunately out of the 4 SPI controllers that the ESP32 comes with, only two are user-accessible, the others are used by the Flash.

Since I the current prototype only supports two SPI peripherals, I had to give up on the SD card, and right now all the data is being stored on an Amazon server. My goal with this project is to make it completely independent from an internet connection, so all the data can be logged locally on the SD card, and accessed with an web browser through WiFi. I've also found that the ESP32 has trouble transmitting bigger websites (jQuery, amCharts, bootstrap, etc...) due to memory and bandwith constraints.

[Kjelt]

Can't you multiplex the display and sd card ?
You can buffer data and once in a while write it to the card.

[agehall]

Hang on a second - we are talking about a smart meter and the specs are reaching in to high performance STM32 ranges? This sounds more like a project for the AtTiny end of the spectrum rather than high performance STM32 processors.

I fully understand the desire to go with some sort of module like ESP32 and solve the rest of your needs with peripherals.

And as far as HTTP server issues with ESP32 modules goes, some tweaking might be in order once you fire it up, but done correctly, I have not experienced much of an issue with streaming data from it.

[brucehoult]

The project that I'm working on is a "smart" electricity meter, and the current working prototype is actually based on the ESP32. The problem was that I had three SPI devices that I wanted to attach to the chip (A TFT display, a microSD card reader and an external ADC chip), but unfortunately out of the 4 SPI controllers that the ESP32 comes with, only two are user-accessible, the others are used by the Flash.

How many of those actually need hardware SPI?

The display I guess, and maybe the ADC, depending on how often you do a sample. But I'd bet the bandwidth to the SD card would be low enough to bit-bang the SPI using GPIOs, and maybe the ADC also.

[Kleinstein]

A smart meter should have a smarter program and get away with a smaller µC.

The STM32 chips and especially the high performance ones are hard hit by the supply problems. So if just starting a design, I would not use them and look for something that is better available. Still hard to tell what is available in 5 years when a beginner finishes a 2 MB projects.

[DavidAlfa]

You're asking for a lot of memory, borderlining the transition between microcontroller and cpu/soc (ex. Stm32MP devices).

Consider using a stm32 with external memory controller, ex. 407Z E/G or 429Z E/G/I.
You can map parallel sram and parallel/qspi flash memories using the FMC/FSMC and access them like normal memory for almost everything, even execute code (although way slower).
In the 429 (and upper) you can also use SDRAM, that's the main difference between FSMC (flexible static memory controller) and FMC (works with dynamic memories too).

2 layer PCB is not a problem as long the memory is near the mcu. You have ~100MHz signals, not GHz.

Check the stm32f429 Discovery:

https://www.st.com/en/evaluation-tools/32f429idiscovery.html#documentation

The layout is 2 layer only, nothing impressive.
You have the gerbers, too.

[Siwastaja]

You may need to wait 1-2 years to be able to get STM32 microcontrollers again. For now, you need to limit yourself to only few parts that are available, most are not. Sucks.

In the long run, just bite the bullet and buy a part in QFP case and learn to solder it. It isn't that bad. Look at tutorial videos, etc. You will make it just fine.

Otherwise than that, STM32 devices are quite simple to design in. Leave a jumper for BOOT0 pin so it can be pulled up to Vcc to run factory bootloader, put a crystal and associated capacitors, get any 3V3 regulator, remember 100nF capacitors near all Vdd pins, bring out SWD programming pins but also bring out the UART pins that have the factory bootloader so you can reflash without special tools if needed through the same UART you would be using for development/debug/statistics/whatever.

Look at the actual pin mappings in the datasheet before deciding if you can use a part. If you need say 2 SPIs, 2 UARTS and 2 I2C's, chances are you can't get all of them at the same time even if the device sports 3 SPIs, 3 UARTs and 3 I2C's! If you plan to use DMA, you need to extend this process into looking at the DMA channel mappings in the reference manual, the available mappings may clash and prevent DMA to be simultaneously used for UART1 and SPI2, for example.

[SparkyTD]

How many of those actually need hardware SPI?

The display I guess, and maybe the ADC, depending on how often you do a sample. But I'd bet the bandwidth to the SD card would be low enough to bit-bang the SPI using GPIOs, and maybe the ADC also.

I think all three would need their own SPI interface. The display should remain responsive at all times, and the ADC should be able to sample the voltage waveform + seven channels of current waveform at at least 100-200 samples/cycle (~5-10ksps). The ESP32 is a great little chip, but I had to make some pretty serious compromises due to the lack of enough SPI interfaces.

[DavidAlfa]

You don't need spi interface for every device, that's Chip Enable/Select pin exist.

[Siwastaja]

SD card and display often get their own SPI buses for the obvious bandwidth reasons. Could be QSPI for the SD.

5-10 ksamples/s isn't much so that could likely be multiplexed with something else on the same bus.

But three SPI buses is not that many IMHO. Many mid-range devices have those available. I routinely use three SPIs because, well, why not. Multiplexing many on the same bus is like last resort when I run out of SPI busses.

[SparkyTD]

You don't need spi interface for every device, that's Chip Enable/Select pin exist.

Well, in my prototype the SD reader and the TFT display are on the same board, and they do share a single SPI interface, but the SD protocol is incredibly fragile, and I've run into many issues regarding chip-select, this is why I had to give up on the whole SD card thing for now. My code is mostly multi-threaded (e.g. display update and database service are on separate threads), and I got as far as using Mutexes to ensure that display updates and DB updates can't happen at the same time, but still, I have found that the SD was very very unreliable, and 9 times out of 10 it just wouldn't work. I'm not sure if this is because of bad Arduino libraries, or bad programming from my part.

Plus when I tried using SD with the ESP32, I used SPI, which isn't exactly the fastest thing. An STM32 offers more possibilities, like faster SD protocols (SDMMC/SDIO), and hopefully more reliability.

[DavidAlfa]

SD isn't that fragile, there're tons of projects doing that.
It's the spi sharing what needs to be done carefully, you're probably disabling Enable pin before the spi has finished with the last byte... Very common issue with the spi flags.

Single spi SD can achieve almost 5MB/s, not that slow.
4 bit SD requires a lot more protocol overhead, CRC, I wouldn't do that unless the stm32 has native SD interface.

[SiliconWizard]

As already said. Chip shortage is a major issue at the moment and picking an MCU that's available now and guaranteed to be so in a few months from now is almost impossible. (Well of course you can always overstock anything that fits your requirements and happens to be available right now, which a lot of companies do, which in turn worsens the situation...)

There's a number of STM32 parts that fit your requirements (no more than 2 MB internal flash though, as far as I could find) in the L4, F4, F7 and H7 series. In order of power consumption, roughly... pick what fits.

Right now, for instance, Mouser has the STM32L4R9ZIJ6 with 262 in stock. 2 MB flash, 640 KB RAM. BGA package.
In QFP package, you have the STM32F469BIT7: 2 MB flash, 384 KB  RAM. No stock though.
The STM32L4S9ZIT6 is in QFP package but in very limited stock...

Keep in mind that, apart from the availability issue, with those specs, the MCUs are not going to be cheap. The above parts are all around $20 or above.

OTOH -even though I'm not sure I would consider this at the moment for a commercial product - there's the RP2040, with 264 KB RAM, dual core M0+ and external QSPI flash. I'm pretty sure it would do the trick just fine for a smart meter. But availability in large quantities is pretty unknown.

In any case, you probably should look at MCUs using external QSPI flash. Because MCUs with >= 2 MB internal flash will limit your options drastically at the moment and will be kinda expensive too.

[SparkyTD]

In any case, you probably should look at MCUs using external QSPI flash. Because MCUs with >= 2 MB internal flash will limit your options drastically at the moment and will be kinda expensive too.

I would be okay with external flash, as long as I can find some that's not BGA (so I at least have a slight chance at soldering it myself), and if I can get away with a 2-layer design and easily find resources online for matching the trace-lengths.

I have given up on finding a part that JLCPCB has in stock, so everything BGA is out of the question.

I think I will just get an SMT32 dev board first to familiarize myself with the chip and with the programming before I design my own.

[SiliconWizard]

In any case, you probably should look at MCUs using external QSPI flash. Because MCUs with >= 2 MB internal flash will limit your options drastically at the moment and will be kinda expensive too.

I would be okay with external flash, as long as I can find some that's not BGA (so I at least have a slight chance at soldering it myself), and if I can get away with a 2-layer design and easily find resources online for matching the trace-lengths.

This isn't a problem. You can find a lot of QSPI flash chips in SO8 package. There's nothing really critical about routing QSPI signals either in general. Just keep the connections short. Exact length-matching is rarely required. We're talking about a quad SPI bus, most often SDR, at frequencies in the order of 100/133 Mhz most often.

[Siwastaja]

What are you doing with all the flash?

Storing some logging data in the internal flash? Don't you have the SD card for that?

Nice and large graphics for UI? Consider compression (or accept slightly lower image quality).

Complete large adventure games with quite nice-looking graphics, sounds and music fit in 2MB just fine in early 1990's.

Are you really sure this is a project that should run on a microcontroller? Maybe an application processor would be a better fit? Or an existing SBC?

In other words, what are you doing? How much can you tell about your project?