Breaking the encryption on the Lerdge series mainboards so I can try porting Marlin 2.0 to it.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
sbaseloader.binThe Lerdge-S base loader (if you brick your board and are comfy finding SWD, this would let you reset it).macbinary - 58.79 kB - 06/17/2020 at 16:08 |
|
|
lerdgexboot1.0.2.patched.binPatched bootloader that does not reset security bits on startup. Must be loaded directly with an ST-link, will not load correctly through the lerdge X boot updateroctet-stream - 64.00 kB - 01/10/2019 at 18:33 |
|
|
ST7796S.pdfThis appears to be the LCD controller - most of the commands match up to what we see in the code.Adobe Portable Document Format - 3.40 MB - 01/09/2019 at 18:28 |
|
|
resetlerdge.shscript to call and then flash. Be sure to adjust paths as appropriate.x-sh - 288.00 bytes - 01/03/2019 at 16:16 |
|
|
lerdge_program.cfgopenocd script for resetting.cfg - 312.00 bytes - 01/03/2019 at 16:15 |
|
Today the official build support for Lerdge X, K, and S was merged into Marlin's bug fix branch. LCD Support is still coming but I published a branch which combines LCD, Lerdge, and the upgraded STM32 core for maximum goodness.
This project is nearly complete - what's left to wrap up is details of the K board's FRAM and RGB LEDs.
And then we move on...
After my last post, I realized that with a functional Ledge X and K v1, and someone helping with the Ledge S, I could aim a bit higher. My initial PR was meant to simply get Ledge-X building in Marlin, without LCD. I think now it's reasonable to say we should aim to have X, S, and K working minus the LCD. Whether or not we hold for the TFT pull request is another issue, and will largely be controlled by whether or not the TFT PR lands first. I know there's something wrong in current code where the init sequences aren't working, and I know a range of commits that broke it, and when I'm home, I'll gradually suss out which one is at fault. Also, I've found that I'm missing some pin information for the X (the transistor which enables/disables the divider network for thermistor use), so it'll be back to the multimeter for that.
I managed to unbrick my Lerdge K board (the bootloader dump sketch left it in a "SWD no longer works" state), and reset it with the K bootloader I have uploaded here, so the files are definitely good. I've also generalized the marlin build environment for Lerdge so adding support for K can be done with minimal fuss, but it will be at least a week before I have more hacking time.
A user contacted me who had a Lerdge S board, and flashed a build of Marlin for the X on it. It turns out the information I was given, that the pins were similar to the X, is not accurate, but that user is hacking away on the pins definitions, so S support will eventually be a thing.
The Lerdge S LCD reports itself as an 0x800C LCD...which is nothing.
But, it's definitely an ST7796. Forcing the override allows Marlin with LCD to boot on the S.
So that is definitely progress. Happy hacking, folks. See you in a week.
While we wait on Lerdge X support to be merged into Marlin...how about getting the new TFT UI up and running?
I had to extract Lerdge's init sequence from the binary and do a few other things. Note, the UI is scaled for a smaller screen, a known problem we're going to fix, but here it is - touch and all.
I'm working with the dev who is doing the primary TFT support to make sure it'll run on the X (and K) out of the box. Next update will be when we have a proper sized UI to show off...
There's been quite a break in updates on this project and that's for good reason. I do this for fun, and it stopped being fun. However, after the completion of the Chitu (Tronxy) work, I decided to loop back around. Marlin has evolved, the ST Arduino core has evolved. Everything has evolved...so I decided to start again.
It took quite a bit of messing around but I was able to get Marlin 2.0 running without LCD, building and encrypting automatically for LerdgeX (K is a different variant. The same scripts will be used but you need a different pin set for the variant and I'm not looking at that yet.
The PR is out to add support for Lerdge to Marlin.
No LCD, but you've seen it work (hell, the code is in my repo). With the new TFT support coming to Marlin, it is a matter of time.
You can follow the PR here:
Marlin's bugfix-2.0.x now contains pin definitions for the Lerdge X and K. I don't own an S, so I have no idea what the pins are. Next steps are to figure out if we HAVE to have a specific board definition (my suspicion is "yes") or if we can build with a generic variant. The reason I think we'd need a specific variant is that the variant's pin config specifices which pins are used by an ADC, and on Lerdge I had issues with the bed pin not having a default ADC definition (I had to uncomment it).
Tomorrow I'm hoping to get the Lerdge-S pinouts from Lerdge. Tonight, I dusted off the repositories and got everything compiling enough to make pull requests for pins. That'll be the beginning of getting this into Marlin 2.9 proper. There's a number of problems with the boot screens and touch controller, but we'll get it running.
A week ago, my STM32F4xx mcudev black board arrived, with a fun STM32F4 processor on it and a TFT LCD interface. I also ordered the cheapest LCD I could find on AliExpress, an Orise clone that specifically mentioned supporting FSMC access. The pinout wasn't identical to what the STM32F4XX wanted, but with a nest of jumper wires, I hooked them up to the right ports.
Why?
I want to build a nice, generic FSMC library where I can tell it the configuration and let it do the rest, and FSMC code is very picky. I found a sample for Keil MDK (which is very expensive) and slowly began cutting it over from the Standard Peripheral Library to the ST HAL. Finally, I managed to get some code that successfully initialize the LCD, but the Orise is an oddity - it can be hard reset from software. The reset pin isn't even used during init. Most LCDs require a reset sequence (lerdge certainly does).
The other advantage of this hardware is that it has an XPT2064 resistive touch, just like the lerdge, meaning that next I can hook the four wires (SPI + Interrupt) for the touch, and get that working.
Lastly, SDIO + DMA will be the end goal, with DMA from an aligned buffer. Touch work will come first.
The next few stages are not going to be terribly entertaining. As noted, I need to get the pin mappings into Marlin 2.x, which will produce an absolutely *minimal* printer. I don't say that lightly, I mean it - no SD, no LCD, no...most of the pretty bits. But once that's working and in, I can switch modes. I ordered from China (and just received) a beautiful little blackpill board - that's an STM32F4 system with SDIO SD card and a FMSC LCD interface.
Just like the lerdge boards.
What this means is that I can develop SDIO support for HAL_STM32 on a system that's actually designed for debugging, then move the code over to support Lerdge.
LCD? Same deal. The LCD in question uses a different command set, but that's irrelevant - I will wire it up identically and use it to debug FMSC LCD interaction, followed by U8G LCD interaction...followed by moving the code to Marlin. THe LCD supports the exact same XPT chip, so I can even debug touch interaction.
But first, I am going to finish out the M200 work.
My other project, Marlin 2.x on the Monoprice Mini/Malyan M200, is slowly starting to function, and there's a few benefits from that for my lerdge project. First off, I have a much better grip on how USB support has to work. Secondly, I've identified a few problems with PWM that have to be resolved -and also we need a better way to handle timers in the ST HAL. The problem is that F_CPU is used to derive some of the prescalar values for a timer, but that will vary based on the board's clock config. For instance, I could underclock an STM32F103 to 48mhz and USB/timers will still work fine. The RCC_GetClockConfiguration function will get us the clock divisors, and with a helper function to get every timer's proper clock source and divide out by the proper scaler, it should work.
Create an account to leave a comment. Already have an account? Log In.
I was thinking that in stead of flashing Marlin on to Lerdge board is to reverse engineered their own firmware and make it open source, that way we can modify current lerdge board and fix bugs our self, Marlin on board which doesn't support is pointless because we have plenty 32 bit capable board which support Marlin and are in a price range of a Lerdge board.
You could work to convince them. I simply wanted to give people a choice.
Loader for Lerge K which is broken here, and the forum is dead, what a pity.
I just tested and reflashed my K with the bootloader. Perhaps there's a different one for different revisions.
Thank you for your work. I'm trying to revive the K board. After pouring the K bootloader blue screen without text and blink the lamp. there is no reaction to file force bin on the SD card. If I use the bootloader from the X armor, the board begins to squeak and respond to the card. But it remains on the article "No App". It's like I'm doing something wrong.
Good health! Tell me how to return the original Lerdge K bootloader via STLink
Does anybody have a pinout for the accessory connector? Toasted board's UART, but there is USB on it? Can I have a pinout please?
Have y fcsm pins schematics on LCD port? Is possible to attach some other cheap LCD to lerdge K board?
are there eventually going to be any instructions via a reader file so one would be able to repeat the process and get marlin on their board. I recently ordered a k board before I found out the firmware is closed. I'm a builder not much of a programmer but I can follow directions if there are any
I'm looking forward to more updates as well. I have a Two Trees SAPPHIRE-S Corexy that has a Lerdge X controlling it, on the way.
Some - I have the code compiling. I'm working on a PIO environment where this can build and encrypt from the command line like the other boards rather than Arduino + script. The BTT Pro work going on for SD Support will benefit both Lerdge and Chitu, so in many ways, I'm waiting patiently on that.
Thanks for the update! That sounds promising. Since you started this project marlin 2.0 has really matured and I think the ledge board would really do it justice.
Hope you have a happy holiday with you and yours!
If the firmware has already been "opened up" so Marlin can be flashed onto the firmware, I wonder if it would be possible to also flash Klipper onto it? Has anybody investigated this possibility?
Ihttps://github.com/KevinOConnor/klipper/commit/8b9cc62359057a686929cc713ffe2931e2203946 seems to indicate that Klipper supports F4. So, the answer is "maybe."
Bigtreetech posted there code 24 hours ago, stm 32F407. Marlin 2.0.
The Lerdge board seems to be one of the few with a STM32F4 (M4) CPU with FPU. I'd really love to see this work go into a Marlin PR. Do you think it will be long before you can do this?
I have the pins/MB definitions ready, but I've been concentrating on getting the M200 ready for Marlin...
I had a much longer reply. I've been focusing on getting the M200 "done" but just received from China my STM32F4 blackpill so I can debug SDIO and the FSMC LCD code once and for all.
I have 3 boards running now. 2x on a XYZ 3D printer and 1x on a big delta printer. What I can tell as a maker, these boards are great, but …. (there is always a but)
RepRap Gcode M591 is not supported (Filament movement detection(Extr. Jam detection))
WiFi module is available but local network connection is not supported.
Acceleration and deceleration (curves) behavior feels a little clumsy
TMC2208 drivers are superbe are a great fit to the board
Thanks for breaking this open. I have a K on the way, and will be diving into this when the slow boat comes in. It was the board I wanted - 32 bit, 6 off-board stepper drivers were my preferred hardware requirements and I liked the overall layout of the board and connectors to make it easy to keep my wiring neat. However, I was not thrilled with the idea of being locked to their firmware. When this project came up on my feeds, it re-opened that option for me.
Is it possible to restore the stock lerdge firmware once it has been flashed with marlin?
I try to strike a balance between the having a working 3d printer as a household tool, and having the hobby of building and programming 3d printers ;) .
I will dig into the code in time I am sure, but having the ability to fall back on a working solution however imperfect when I just want a print job done would be nice too.
any updates or more progress on this intriguing project?
I burned my lerdge k main chip :(
I will replace stm32f4 chip with new one.
Then flash lergdekloader.bin , whats next ? where get official firmware
Go the official LERDGE website and download your board specific firmware
Hi, I'm a user of two Lerdge S-Boards and now also the Lerdge K-Board and board wise and UI wise I'm really satisfied. (1x Delta 2x Cartesian)
What I mis is the local network connection. Their own ESP solution doesn't work for local network connection (works only for a Chinese android app)
Setting up the ESP module as some have suggested in this project doesn't work neither other than I can sign in to the ESP module but no way I can communicate files to the printer or to it's SD card.
Question: would it be possible to make the ESP connection to work in order to upload files to the Lerdge SD card via the program WinSCP or otherwise?
I tried to contact the vendor to hear about their opinion to open up for the hardware (so that e,g. Marlin 2.0 could be used). But they have no plans at the moment... A pity, as I think the board would have a huge potential customer base, if customers had the option to load open-source firmware to the controllers...
You can load marlin on the board NOW. Lerdge's input is irrelevant at this point. They could make things better and faster by supporting it themselves, or we can go the slow route. All my code is public, the tools are public, you could compile right now. You probably wouldn't be delighted with the result, but it would work.
They are Shenzhen based so It might be worth a shot to check with Naomi Wu if she has (or can get) connections, and perhaps spread the virtues of opensource to them. :)
I have tried to write a message to Naomi Wu via Facebook... Now I will just have to wait and see if she answers / and what she thinks..
Is the marlin firmware able to take advantage of the FPU on the MCU?
Become a member to follow this project and never miss any updates
how much work do you think needs to be done to be able to run Klipper at this point in time?