From PIC to STM32

[Veketti]

Hi,

Inspired by DavidAlpha’s post on another thread I got thought of starting to replace my mostly utilized PIC16F1847 to STM32G050F6. I’ve done one project earlier with STM32L4S5ZIT and already have Mikroelectronica Fusion for STM32 v8 development board, but they’re not providing MCU card for STM32G050F6..
1. So my question is how would I do the development with this TSSOP 20 MCU? Would it be so simple to solder the MCU to "SSOP-20 to DIP" adapter and use breadboard?
2. Does this transfer to STM make any sense and would this MCU do all the stuff PIC would as long as it has the support for same peripherals?
3. Last but not least. How to program it easiest by ST/link V2 with the 20 pin flat cable. Previous project I implemented the whole 20 pin connector to PCB. There must be easier way. Is there any information how to program with lesser pins with ST/link?

Thank you in advance

[ataradov]

1. Yes, it would work. You generally want power supply decoupling capacitors close to the MCU, so ideally on the same breakout board. I would try to mount them locally, but for  G0 it might not matter that much.
2. Sure. Pretty much anything will do what PIC does.
3. Cortex-M0 devices only need 3 wires for programming GND/SWDIO/SWCLK. Reset is desirable, but not mandatory. And some debuggers would need target VCC to power I/O buffers.

How you break that out from the full 20-pin connector is up to you. You can make a simple adapter or use standard 0.05" 2x5 Cortex-Mx debug connector and use existing adapters and tools that have that connectors directly.  On a breadboard you will likely have to use flying wires unless you make some breadboard friendly adapter.

[Nominal Animal]

Would it be so simple to solder the MCU to "SSOP-20 to DIP" adapter and use breadboard?

Per the datasheet, you'll want to add some supply bypass capacitors (see 5.1.6 Power supply scheme).  Also note that its maximum supply voltage is 3.6 V, so you might wish to add a voltage regulator or switchmode controller for easier powering.

I recommend you also read AN5096 - Getting started with STM32G0 series hardware development application note.

Is there any information how to program with lesser pins with ST/link?

It has an ARM Coresight SWD debug port, so for the TSSOP-20 package, you only need to connect VDD (pin 4), VSS/GND (pin 5), SWDIO (pin 18), SWCLK (pin 19), and NRST (pin 6).  (I.e., two signal lines, a reset line, supply, and ground.)

To connect any STM32G0 in TSSOP-20 to ST/Link V2:

• VDD: ST/Link pins 1 and 2 –– TSSOP-20 pin 4
• VSS/GND: ST/Link pins 12, 18, and 20  –– TSSOP-20 pin 5
• NRST: ST/Link pin 15 –– TSSOP-20 pin 6
• SWDIO: ST/Link pin 7 –– TSSOP-20 pin 18
• SWCLK: ST/Link pin 9 –– TSSOP-20 pin 19

as described in AN5096 chapter 4.3.3 and ST-Link/V2 User Manual table 4.

[nctnico]

1. Yes, it would work. You generally want power supply decoupling capacitors close to the MCU, so ideally on the same breakout board. I would try to mount them locally, but for  G0 it might not matter that much.
2. Sure. Pretty much anything will do what PIC does.
3. Cortex-M0 devices only need 3 wires for programming GND/SWDIO/SWCLK. Reset is desirable, but not mandatory. And some debuggers would need target VCC to power I/O buffers.

Better connect the reset line though. I've seen trouble getting some ST controllers to talk to the SWD interface without the reset line connected.

[DavidAlfa]

My advice is to buy a cheap board from AliExpress, less trouble, buy & use!
I bought this one to evaluate the G030, but the G050 pinout should be compatible, so you can simply swap it.
https://a.aliexpress.com/_ExJOvrH

And yeah, the stm32 will blow the PIC out of the water.
Harvard architecture sucks, it got really old, not having separate program and data busses or memory banks makes thing so much better, easier and versatile, everything is accesible in a linear memory map.
Much better peripherals and so much faster cpu while doing more with less instructions.
It's a steep learning curve coming from PIC, but once you get used to it you won't look back.

[nctnico]

May I suggest not to blindly follow everyone into STM32. Especially for a beginner, NXP's LPC series of ARM microcontrollers are much easier to get going with. Better (correct!) and clearer documentation, peripherals that are designed so that they are easy to configure and all of the controllers have a serial bootloader besides SWD. I have been using both and I'd take an NXP LPC series over an STM32 any day because the latter just take more time to get going.

[Psi]

if you normal write code to directly talk to the registers to access peripherals then your transition to STM32 maybe a bit rough. Lots of new stuff to learn.
You can setup the registers manually on stm32, but because it's much more complex than older 8bit mcus the hardware is harder to control and has many more options.
You normally use their standard peripheral library as an abstraction layer between your code and the hardware.
Using a standard peripheral library can be a bit of a learning curve and STM32 was a bit of a mess when I last used it. Granted that was a while ago.
One annoying thing I remember was trying to search for example code. You will find lots of code but it's usually written for a version of the standard peripheral library that you're not using, so it wont work.

[newbrain]

Would it be so simple to solder the MCU to "SSOP-20 to DIP" adapter and use breadboard?

Works for me. In the horrible (in)animated gif, an STM32G030, running Rust.
The connections are to 3.3 V and SWDIO/SWDCK.
The only other component is a 0805 100 nF decoupling cap soldered between Vdd and Vss, under the adapter board.

EtA: the dog* ate the GIF animation for reasons inscrutable to me.
*forum SW.

[peter-h]

I implement a 10-pin connector on my boards

https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging-and-njtrst-mystery-does-it-do-anything/

with a 0.1" pitch for spring-loaded contacts. There are various other production load probes out there but I never bothered with them.

For production programming I use the 8-pin header shown, and for development work I solder in the 10-pin dual row connector which mates with the same connector that comes with the various STLINK variants (I use STLINK V3); Olimex also do adaptors for this stuff.

[Veketti]

This was quite comprehensive, but still had to connect one more pin and that was from ST/Link V2, pin 19 to VDD for power supply. I quess below connection is ok if there is external power supply connected?

To connect any STM32G0 in TSSOP-20 to ST/Link V2:

• VDD: ST/Link pins 1 and 2 –– TSSOP-20 pin 4
• VSS/GND: ST/Link pins 12, 18, and 20  –– TSSOP-20 pin 5
• NRST: ST/Link pin 15 –– TSSOP-20 pin 6
• SWDIO: ST/Link pin 7 –– TSSOP-20 pin 18
• SWCLK: ST/Link pin 9 –– TSSOP-20 pin 19

as described in AN5096 chapter 4.3.3 and ST-Link/V2 User Manual table 4.

[DavidAlfa]

Better avoid connecting VDD to the STM32 when powering the board externally.
Rest are OK.

[NorthGuy]

2. Does this transfer to STM make any sense and would this MCU do all the stuff PIC would as long as it has the support for same peripherals?

It's always good to try new things. STM has much faster CPU and much faster ADCs, so you should be able to do more than you did with PIC16F1847.

Whether it's most suitable for your current project depends on your project and its requirements. But to figure that out you need some experience with variety of chips. If you don't, keep trying different things and broaden your experience.

[hans]

Many debug probes have I/O buffers, and then need VDD to power their DUT I/O side.
Otherwise you can leave it floating.

I typically use the 10-pin Cortex Debug connector. I think its ARM standardized SWD connector. 2x5 with 1.27mm pitch is still fairly compact, but not fiddly to use. Its featured on JLink Mini Edu or, with a 10$ adapter, with the 20-pin JTAG/SWD connector (which is enormous)
But if a pin header and some Dupont wires to a Nucleo/STLink is easier, then obviously do that.


The debugging and programming itself is done using SWDIO and SWDCLK wires. RST is sometimes useful if your MCU goes into sleep and cannot be probed over SWD without a reset. The SWO pin is basically an UART within the ARM core that can be used for low-end tracing or printing data, but I don't think the Cortex-m0+ has that feature.

Note that most STM32s also has a BOOT0 and sometimes BOOT1 pin. These are usually multiplexed on some GPIO. I've never ran into such severe I/O shortage that I had to use that pin for I/O purposes, so I typically just put a pull-down resistor on BOOT0. Pulling BOOT0 high at reset would jump into the internal bootloader, which can sometimes be useful if you accidentally brick a device, (like turning off all oscillators). On larger devboards I may put a switch/button on that pin for easier access.

Other than that the connections are similar to a PIC. Apply power with some 100nF decoupling caps, maybe an oscillator (optional just on modern PICs), and away you go. The pin table contains all the multiplexed functions for an I/O port, which you have to configure using the alternate function mapping (its all in the datasheet).

Oh, and if this is first time using ARM MCUs: don't forget to enable to the clock to a peripheral using the RCC macros (e.g. __HAL_RCC_GPIOA_CLK_ENABLE(); for GPIO port A). That costed me a couple of hours when I first got started on ARM.

[fchk]

Inspired by DavidAlpha’s post on another thread I got thought of starting to replace my mostly utilized PIC16F1847 to STM32G050F6.

You are aware that PIC ist not only 8bit? There are plenty of 16 and 32 bit PIC24, PIC32 and dsPIC parts. There are PIC24 and dsPIC33 parts designed for 5V. There are even dual-core dsPICs. and many parts up to 28 pins are available in DIP packages.

You can keep using your known environment, swap only the XC8 for XC16 or XC32. The peripherials are not exactly the same but very similar. This would be a fast way to get things done.

[zapta]

You can use this one, or if it's pin compatible with the other MCU you want to use, solder it in instead.

https://www.aliexpress.us/item/3256805562181743.html

If it's for a hobby, you want to use a popular SMT32 that is available on Ali, supported by platformio, and so on.

[Veketti]

If I may continue to this regarding the development environment. As there are no development board for every type of MCU, how is the code to be ported to different MCU model? For example, you'll use STM32L476RET6 in final product, but closest development board is 511-NUCLEO-L476RG which has STM32L476RG mcu. It's the same family but with more flash memory. I'd assume, you'd just develop the code for the Nucleo in CubeIDE, then once finished start new project with STM32L476RET6. Then define all the same pins, clocks, exatly the same than what it was for Nucleo. Then copy all your code from between the /*USED CODE xx*/ tags and cross your fingers that it works on your PCB?

Or perhaps there's an easier way, like just change the MCU type and press generate? 

[Siwastaja]

If I may continue to this regarding the development environment. As there are no development board for every type of MCU, how is the code to be ported to different MCU model? For example, you'll use STM32L476RET6 in final product, but closest development board is 511-NUCLEO-L476RG which has STM32L476RG mcu.

Just build your own board using the final chip. I almost never use the "development boards", they are simply too far from the final application and you would spend a lot of time breadboarding hardware around the devboard. While the results of these breadboarding tests are useful, the work itself goes to waste.

The reason is simple: you will have some custom electronics that need development and testing anyway. By doing very first revision of the final board, you can develop HW/SW in parallel. Even the quickly designed "prototype zero" board will reveal hardware problems, ideas, etc., which is extremely helpful when designing the next revision, which could be very close to the final product. "Prototype zero" can also be shown to management, customers, etc.; it's the first step in right direction, but changes are still easy to make.

For example:
1) board revision 0, design in a few days, ignore time-consuming parts and don't try to optimize to perfect design; order boards from China ASAP
2) during wait time, finish BOM details (like resistor values), order components, start writing software
3) components arrive. Keep writing software
4) boards/stencils arrive. Now you have components, board and some initial version of your firmware. Hand-assemble and start real development work.

[SuzyC]

Siwastaja, special thanks for such clear advice!

My problem is that I am such a Noob and so not able to layout a proto rev 0 board because I lack the basic familiarity with working with a 3.3 ARM M0 chip and I need to experiment with a STM ARM M0 chip on a working proto board to learn the chio's quirks/capabilities to begin with. I got to setup a work environment/toolchain.