Lerdge 3d Printer Mainboard Hacking

I've been fairly busy at work (as in the job that pays the bills) but I ordered a knob for my lerdge X and soldered it in. Lerdge X and K pin mappings seem to be right, though since I'm not remotely using all the functions I can't be certain everything works (led strips? No. Probe? No. Motor fan, etc? Hahahahahaahaha) My test printer is literally a Monoprice Mini I wired adapters up for (see my other project for hacking on that).  

I'll start a PR to Marlin main to add X and K boards soon.

I'll be away from my hardware and most of my software for the next few weeks, so good luck hacking, people. It's important to unplug every now and then. Have a good time, I'll see everyone next month.

I was fairly close to getting everything running, and as I mentioned, this last stage is painful in that things *almost* work. I discovered a few new problems:

1. There's a random SDIO error that causes printing to error out. I hooked up Octoprint and proceeded anyway.

2. My travel settings are way, way too agressive for the little MPSM I wired this into. The printer doesn't move fast normally, and you can see it shakes and rattles quite badly during the video.

3. Steppers STILL aren't adjusted right. X skipped a step at the bottom, causing a shift (and at the top, the person operating the printer failed to get their hand out of the way of the print head, causing another). 

4. A partial clog midway through the print caused that ugly layer in the middle, a minor shift caused the bulge below it.

Despite all these problems, the printer works. The pins are correct, almost everything works except one of the LCD buttons, which isn't defined right for some reason. I'll begin a PR to get the pins added to Marlin once I have that fixed.

I was fairly close to being ready to declare this printer running at an alpha state and add it to the Marlin 2.0 compatibility table. All I had to do was get a few test prints done and I'd be happy.

Easy, right?

First, I found an issue with my variant in Arduino. In ST's core, every pin has to be mapped to an ADC if it's going to be used for analogRead(). And guess who didn't have an ADC for the hotend pin.

Easy fix.

I wire everything up...and still don't get a reading. This sent me down a rabbit hole checking and rechecking, but finally I hit an easier answer. We're at the part of the project where theory meets reality, and the bits and wires intersect.

I had a broken thermistor. I don't know where it's broken, but it is. So I wired in a new one...and discovered my hotend was destroyed. How did this happen?

One of the last fixes I did fixed the E0_AUTO_FAN, so the hotend is automatically cooled. But right before that, I'd done a temperature test, and (sigh) cooked the PFTE liner in my hotend. 

Good news? Thermal runaway detection at both min-temp and max temp works 100%.

Bad news? I'm wiring a new hotend into the printer.

At that point, I'll print the lucky cat...and have a beer.]

I've got a minimal marlin build up and running on both X and K, with the boards wired into a printer to test with. Doing so has revealed a few problems I would not have seen otherwise:

1. My LCD isn't filling the background correctly. The Logo during boot appears clipped, and the boarders are not filled in black.

2. Hotend temperatures read from PC1 are not working correctly. i can swap the pin definition to PC0, swap the connector, and the hotend behaves correct. This doesn't affect the MP MIni, so it's not clear to me what might be happening.

The solution for #2 is to write some diagnostic code to narrow down if pure, plain "analog read" works for the pins. Once basic pins are verified, I'll begin PRs to add this to Marlin main.

Just a note that adding the I2C EEPROM definition to the Lerdge pins and enabling #EEPROM in the configuration was all it took to get settings to save correctly. Next up, I want to take a swing at emulating the 3 button interface on the touch screen, since unlike Mickey, I don't currently have an encoder (it's on a boat from China). 

We're getting there. This weekend I'll be wiring the Lerdge-X into a printer.

With the help from Jason, Dzenik, and jmz52's help I was able to adapt my custom version of Marlin4MPMD to work with the LerdgeX hardware.  The majority of the work was spent adding in the STM32F4 HAL library instead of the STM32F0 HAL library, and then running through inconsistencies with the Lerdge hardware.  As a proof of concept I now have full functionality including motion, auto bed leveling, SD support, a janky looking version of the Marlin GUI, and Octoprint support.

Because it is derived from Marlin4ST originally, the fork is based off of an older Marlin 1.x base and is only compilable through openstm32, which is a lot more complicated to generate and install binaries through.  Given the current development state of STM32 arduino support, it made more sense for me to continue bare metal development to make this proof of concept.  The right way to move forward however is to provide HAL support through Marlin 2.0, which is what future efforts will entail.

One of the key difficulties developing for Lerdge was centered around the issue of the STM security bits.  By default, both the bootloader and the application binaries include a piece of code that will enable the security bits of the processor.  This is intended as a copy-protection feature that will erase the entire flash memory if the device is reprogrammed over SWD.  However, by side-loading our own custom binary that reads out the entire flash image we can extract the raw code for the bootloader and application binaries and modify them to disable this check.  I've added a patched version of the 1.0.2 bootloader.  This is import because it allows direct debugging and loading of application code on the processor without triggering a full erase.

The LCD code was another challenge in that we had an unknown panel with an unknown pinout connected via ribbon cable.  Through some sleuthing we were able to determine that the communication was done over a 16-bit parallel data interface to the panel and the FSMC peripheral was used to send/receive commands.  After deducing that standard 0x2A(row select), 0x2A(column select), 0x2C(RAM write) sequence was able to change the colors on the panel, I deduced it was similar model to the ILI3941.  However, reading the device ID provides 0x7796, which indicates it is likely a generic ST7796 panel instead, which coincidentally shares the same command set as the ILI device.  With this and some code provided by jmz52 to scale up the Marlin output to a larger resolution, I was able to provide the Marlin GUI to cover most of the Lerdge screen.

This was intended as a proof of concept more so something to be distributed, IMO the best course of action is to wait until full Marlin 2.0 support is provided.

With some help from Dzenik, I managed to get a working LCD on Marlin 2.x, though some of it is hacked together. Initialization isn't working the way I'd expect, so I'm manually calling the LCD init code.

After that, the LCD writes just work, though I don't currently have pixel tripling working.

Now, Mickey had already gotten the LCD working on his Marlin build - his is based off of Marlin4ST, mine is from 2.x, but we're both working toward the same goal.  I'll get the scaling working soon, then hammer out the issues with LCD init so it works with U8G the way we'd expect.

Sometimes, it's less about what you do and more about what other people are doing around you.  In this case, someone was already working on adding support for SDIO to Marlin.

This gave a nice way to abstract away the details of block reading, and THAT gave me a simple way to plug in code. I started using the STM32SD library (and still am using code derived from it) but hit a problem where no matter what, the block reads failed.

After a great deal of investigation, I found that the block read calls were passing in the block SIZE as the block number, meaning that in many cases, huge chunks of memory were getting trampled.  A few fixes later, we have the following output from the ESP8266:

M20
Begin file list
echo:Cannot open subdir JOURNA~1.COR
echo:Cannot open subdir JOURNA~1.LIV
echo:Cannot open subdir JOURNA~1.COR
echo:Cannot open subdir JOURNA~1.SCA
echo:Cannot open subdir JOURNA~1.LIV
echo:Cannot open subdir JOURNA~1.COR
echo:Cannot open subdir JOURNA~3.LIV
TEST.GCO 304884
TES~1.GCO 304884
End file list
ok

This code needs to be vastly cleaned up - I literally imported the bsp_sd h and c files directly, but they don't use DMA, there's the afore-mentioned "passing the wrong parameters" bug, and in general, a lot to do before I can proclaim it works. Also troubling is that if I re-init the SD card, it crashes, but that's a problem for another day. 

Getting closer and closer to that first test print.

Also, another member has successfully initialized and written to the LCD. I haven't done this yet, but they have. So, bit by bit, it's coming together.

I'm uploading the cfg and scripts I use to reset the lerdge board. THe paths on these are probably all wrong, but it should make your life a little easier if you're hacking.