DO NOT USE SPC5 STUDIO

[MBedl.1]

For everyone who is thinking about starting a project on an SPC5x MCU: don’t. Just don’t. On paper, it looks great. Beautiful marketing slides. Pin mapping, clock tree, HW initialization… a cheap multicore debugger… everything you could ever want. Amazing. 

You want to set the clock? Cute. Unfortunately, for your E-family MCU, there is no clock tree. Because… reasons.

Oh, you want to set up GTM? No problem! There’s a default configuration, just pick what you need. Just don’t pick ATOM3. Or ATOM4. Or anything beyond ATOM2, really. It won’t work. No warning, no error, no hint. It just silently does nothing. What about ST support? Haha. Good one. You already designed your PCB using ATOM3? Congratulations. You can now spend a few months trying to make it work before finally hot-wiring your board like it’s a Soviet-era radio, just to avoid ATOM3. Along the way, enjoy the complete lack of driver documentation.

Good job! After enough pain, your basic application is now somehow running.

Time for a new prototype. Your application needs more performance. No problem, just pick a higher MCU family. It should have a clock tree, the app should be compatible, and maybe—just maybe—ATOM3 will finally work.

Surprise! ATOM3 still doesn’t work. But now it’s better: enabling it crashes your application right at startup. Progress! Luckily, you designed your board so it can limp along without it. Still, having a fully functional MCU would be nice. Spend a few more months fighting poorly documented drivers. Then, completely by accident while debugging something unrelated, you discover the real issue: a GTM clock divider. No description. No warning. Default value? Zero. Everything else is configured correctly, but this one magical divider is zero by default. Of course it is.

Fine. ATOM3 works now.
But wait… why is everything so slow?

This MCU should have plenty of horsepower, yet it struggles with a not-so-complex application. Is it the compiler? Yes. Obviously. You can even set compiler attributes directly in the configurator. That’s adorable. Unfortunately, the configurator feeds the compiler wrong MCU information, so the compiler politely ignores everything you set. Want it fixed? Patch it yourself. Character-building exercise.

What about that cheap multicore debugger from the ads? Yeah… no. Multicore debugging doesn’t work. Why? Ask ST. Silence. Ask PLS. Response: “Not our product – ask ST.” Perfect. Let’s look for another debugger. Oh. That one costs more than the entire project budget. Excellent.

After many months, you end up with a mostly working application. It has plenty of bugs, but debugging them is more of a philosophical concept than a practical possibility. Now comes the big decision: scrap everything and start over with a different MCU, or continue digging this hole until you reach the Earth’s core.

Fine. Let’s at least get the watchdog working.

After many failed attempts—because the configurator won’t let you edit grayed-out columns—you start asking existential questions. It works in the example. Why not in my app? Compare XML files. Edit them by hand. Sacrifice some dignity. Eventually you discover it’s just another bug: SWT0, SWT1, and SWT3 switches do absolutely nothing, while SWT2 magically unlocks all of them. Makes perfect sense.

One configuration change takes minutes. Scrolling with the mouse wheel randomly changes columns under the cursor, just in case you weren’t annoyed enough already.

Please, for the love of engineers everywhere, put a warning on the SPC5 Studio download page.

[Lina_DABASINSKAITE]

Hello @MBedl.1,
 
Thank you for your feedback on the SPC5x microcontroller and its tools. We regret the difficulties you encountered during your development process. 

Your comments on clock configuration, GTM module, documentation, and debugging tools are valuable. We recognize the importance of reliable documentation and tool support. We apologize for the inconvenience caused by unclear warnings, incomplete documentation, and IDE or debugger issues. 

We take your concerns seriously and are committed to taking concrete actions to improve our products and support. To provide targeted assistance, a technical support team member will contact you directly to address your issues in early 2026.  
 
Best regards, 
Lina 

[Sir_Alee]

I had similar Issues with all sorts of components just like MBedl.1. I eventually got everything I required to work with some workarounds. Whats really annoying is the lack of a reference guide for the SPCStudio on what the low level driver do, how to properly configure them and documentation on the functions. I found some configuration snippets like an5695 or an5552 and the examples for the discovery boards which where very helpful but also the 3500 pages rm0408 which had nothing to do with the programming of this MCU in SPCStudio. On top of that there are multiple erroneous pin swaps in the documentation of the SPC574k Discovery board (um2155) which took me a long time to notice. I also had trouble with SPI frame sizes. When I configure a 32bit frame size, SPCStudio will not generate and throws an error. Other smaller frames work fine, very annoying.

When everything is implemented the MCU works great. I also like the fact that I can setup the compiler in CLion from Jetbrains and basically do all the code writing and compiling there. But if I had been on a fixed budget, had a hard deadline or would not had a lot of experience with other MCUs my project would have failed or it would be a dangling mess of buggy "features" waiting to ruin my day.

At this point don't get me wrong I do like the SPC5 MCUs. I had multiple projects with these chips and the lower you go with the controller series, things really do work without much trouble shooting. But please please please get someone to write documentation for SPCStudio, something like esspressif did with its idf framework where every driver is described on what it does how to add it and set it up and what functions do what.

Kind regards