Close

HAL-lo

A project log for Monoprice Mini Marlin 2.0 Support

Getting Marlin to run on the Monoprice Mini/Malyan M200.

jc-nelsonJ.C. Nelson 05/11/2018 at 20:420 Comments

While doing fun things like tinkering with the blink sample (I'd done some arduino projects before, building a nutrient dispenser for a hydroponic vegetable farm), I asked some questions on the Marlin 32 bit development thread, and found out someone had already beaten me to the hard work of writing a HAL.

This is not a bad thing.

I mean, really, I'd already written ADC support, some GPIO mapping functions, and a smattering of other stuff, but this was a chance to leapfrog ahead.

Github User (and apparent long time STM32duino hacker) VictorPV had a working HAL which I could compile to produce a version of Marlin which ran on the bluepill. 

But that same binary didn't run when I flashed it on the Mini...

Here, I got some help from someone on the Monoprice Mini Facebook User's group - a person there had a mainboard with a blown stepper driver, and for the cost of shipping, he mailed it to me. I promptly soldered on wires to the ST-link headers and reset the chip, erasing the bootloader, but letting me flash software directly on.

But despite my work, the board still didn't show up in device manager.

So I began digging.

First off, I discovered the vector table address wasn't being set correctly. PlatformIO uses a series of python scripts to build targets, and this one didn't set the vector table address correctly.

I created a patch that pulled the vector table from the board's json descriptor (which would later get put into a pull request for the main branch).

Rebuild, Reflash, no luck.

I could see in the compiler output the correct vector table address, but the resulting binary *looked* wrong when I looked at the addresses in a hex editor.

I shelved it for a couple days to think (and wait for some hardware to arrive). This time, it was a level shifter for 5v->3.3v and a USB->TTL converter, which I promptly wired together into the most hacked up way possible. 

On the MP Mini, the LCD is connected to Serial1, so I cut the cable in half and soldered it to my level shifter, producing a way to monitor the Mini's serial output from my computer.

A quick test with a fully functional board showed me a couple of things:

1. No matter what Malyan said, it was probably some variant of Marlin running on the Mini - the startup spew is identical to what Marlin 1.0.x printed.

2. After its initialization, the beautiful 8,n,1 at 500000 output became garbage.

This didn't bother me at all. In fact, it confirmed a few things - that Malyan had likely ported some flavor or derivative of Marlin, and that my hardware worked for monitoring. 

I recompiled my test program, set to output a single string: "Hello from inside the mini!" over and over, and pointed it at Serial 1.

No joy.

But when I searched for the vector table address, 0x8002000, I found something interesting in the STM32duino code. Each board has a linker script, or .ld file, and that file specifies address the linker will use to assemble the bits.

A quick edit of this file, a full recompile (PIO doesnt' always work when updating LD files. It does when you change the builder .py files, though, and it never correctly detects .ld files which are #included), and..I had to go fix dinner.

It was close to bed-time when I finally got a chance to pop the SD card in, start the monitor, and flick on the power.

And there was my string, repeating itself a thousand times--and then freezing, restarting, and repeating.

This was progress.

Discussions