A few months after I got everything running, Malyan released a V2 of the M200 (and right now there's a V3, called the Pro, preparing to release). The early run V2s, of which I have one, contained an STM32F103 MCU, and my code simply worked on them.

Later run V2s, however, contain an STM32F070 "value line" MCU, which is capable of running at a max of 48mhz and contains different timers. I'd say "fewer" but it looks like existing capabilities were reused for other purposes in the chip.

And that lead me to a real problem.

V2 was built using a framework called STM32DUINO, which supported F103 and F4 MCUs. It did not support 070 at all.

Some investigation showed that a arduino framework called STM32GENERIC, based on the CMSIS/HAL code did support 070 in a fashion.

PlatformIO, however, did not allow building with STM32GENERIC as a core.

What followed was a period where not much happened on the marlin side of things, as I learned how platformio building worked, used a builder someone else had already created as a starting point, and produced a private platform by which I could automatically install what I needed and begin building.

To do so, I needed to host my own fork of the STM32GENERIC core, which was just as well, since it isn't heavily maintained.

After several weeks, I finally reached the point at which if I deleted PIO's package for stm32generic, it would redownload it and install correctly.

This put me in the position where I could first do work to add proper 070 support to STM32generic, then fix some annoying bugs (like it not having systick initialized) and then get around to compiling for the V2, by way of an 070 discovery board.

And my firmware didn't work. Didn't even boot.

No problem: I wrote an 070 version of my "turn on fan" function, and began to debug. After several low level fixes, got something that would start. But timers and ISRs didn't work. Why? I checked and rechecked my vector table addresses. 

When reading the 070 documentation, however, I hit a crucial detail I'd missed. THe 070 doesn't have a vector table offset register. The vector table is always at 0. So how does anything function?

It turns out, you can set a bit to remap 0 to the start of flash ram. At that point, the light went on. Much like on the old commodore 64s, you could remap character tables to rom, you can reserve a bit of space at the beginning of ram by changing the linker's LD script. Then, on startup, copy the vector table from ROM to RAM and remap the vector table mapping.

Now timers worked, but marlin hung. After much debugging, I discovered a critical difference between STM32DUINO and the generic core, that required one marlin change that isn't in yet (you can't initialize a watchdog that's already running). STM32DUINO keeps going, generic hangs. Finally, I had a V2 version running.

In some regards, the result was better than the default - my firmware reliably booted and intiialized USB, where the default doesn't always.