DO NOT USE SPC5 STUDIO. Its a trap!

[MBedl.1]

For everyone who is thinking about starting a project on an SPC5x MCU: don’t. Just don’t. This thing will slowly and methodically destroy your sanity. On paper, it looks great. Beautiful marketing slides. Pin mapping, clock tree, HW initialization… a cheap multicore debugger… everything you could ever want. Amazing. Except it’s all a lie.

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.

All of this happens in what might be the slowest IDE ever created by humanity. 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:
“This is an abandoned alpha version. Use only if you enjoy suffering.”