Looking to collaborate, have some questions

[mcheah]

Hey, thanks for posting the pinout, this saves me a whole bunch of work. I developed an STM32-based Marlin port for the Monoprice Mini Delta and just got a Lerdge board as it's much higher performance. Porting should be pretty easy to do, but I have some questions about the system that I'm hoping you can answer. Specifically I'd like to know how you bypassed the write protect without clearing the flash rom, and how you were able to probe the GPIO pin configuration registers. Hit me up on reddit it'd be nice to work with somebody else on this.

[LoialOtter]

Very welcome. The board is really quite impressive for being so cheap.

The readout protection on the STM32 line is pretty good (I've developed products that made use of it) but there are some interesting issues with it too. One is that protection of RAM and peripherals is optional. I just and hooked up to JTAG and read from those locations on RAM. Note that it's very important that you do it carefully so you don't accidentally read from any location in flash as that will lock down the JTAG access and you'll no longer be able to read from anywhere. I was really not expecting that to work so I had also pulled out my multimeter to do things the old fashioned way.

Once I had the map done there's a way to erase the entire flash by disabling the readout protection. This then leaves you with a fully unlocked but fully erased device.

[mcheah]

Yeah, i did something similar on the stm32F0 firmware on the monoprice printer. I see that both the bootloader and the application bin files are available, so I'm tempted to just blow it all away and start from scratch, but I want to make sure i have the memory map right first. I'm assuming the bootloader ends at 64k, do you know anything about that? Also do you have any info on the LCD / touch screen they used? Tbh I'll likely never implement since the goal is to run off of octoprint. Also do you know why they have so many frikkin mosfets all over the board? Even for the stepper drivers. I'd understand for the heater/fan but it just seems excessive for digital inputs. Maybe they need to level shift to 5V?

[LoialOtter]

The mosfets are proper driving and separation so any current spikes will never hit the CPU. They are proper mosfet drivers so also do level translation IIRC. Honestly the IO is probably the best designed I've ever seen in a reprap community driver board. Everything's been given proper inputs and outputs.

My only real complaint from a 3d printing side is that the heated bed driver isn't on the board so you'll need to add a SSR or mosfet or something for that.

The LCD is being driven by one of the DMAs rather than any special peripheral. This means they have a framebuffer in ram that they're simply drawing to and the DMA just copies that onto the display. The pinout should be pretty obvious. It's just a standard 8080/6800 LCD and there's specs online for the resistive touchpad chip on there; I didn't get too deep into it as I was going to go deal with that later and then got distracted from the project.

As for the bootloader and flash layout, no idea as I'm replacing the whole thing. Don't forget the CPU itself has DFU so you don't need anything special, just pull a pin low when you power it on and it'll come up in windows/linux and you can program - no special bootloader needed.

[mcheah]

I figured they were kind of superfluous since most stepper drivers support CMOS inputs, but I suppose in the case of a short or failure with the high voltage supplies going to them you'd want to protect the CPU. Just a lot higher component count than I'd expect from a board this size and cost. Agreed on the bed driver. My suspicion is that they realized that it'd be difficult route that much power over a small 2-pin connector and opted to have it supplied externally. While that's definitely the more flexible route, it's frustrating because the provided solution is a dongle to a dongle to supply a heatbed and potentially requires a second power supply or a jury rigged connection.

Thanks for the info on the LCD. I have no idea how to look up info on these screens, most the time they come with very few markings and a gigantic parallel bus. It'd be nice if somebody made a nice library for these kind of things. IMO the graphics and UI design for a product like this is probably 3x the work of the motor control part. I'll likely ditch the whole thing and hook up a simple reprap display through the expansion connector.

Yeah, I've got a ST-Link hooked up through the SWD pins already, I need the ability to debug code directly so I'm skipping the DFU route. What are your plans for the firmware? Are you looking to adapt Marlin/RepRap/Klipper/Smoothie to Lerdge? Or build your own from scratch?
The other thing I didn't like about the board is that there's no native USB port for communication, you have a buy an adapter with a CH401 chip. I tried plugging in a USB A<->A M/M but nothing showed up, I think they have it hooked up as host only.

I'd like to retain the ability to run the stock firmware so I can go back and forth to compare functionality. This is how I was able to debug a 5 degree offset on the temperature readings on my Marlin project.

[LoialOtter]

https://github.com/LoialOtter/micropython

[LoialOtter]

M/M works fine. Not standard but hey, you just have to configure the system to not use OTG and instead force device (so a UI is needed if you want it to do host).

The DFU is there as a bootloader for users. I haven't tried erasing a chip using it though that would be interesting. It allows you to ignore their bootloader and just use that if you wish or make one yourself. I've made a few in the past based on ChibiOS which works great on this line of chips.

[mcheah]

Yeah, I'll get it working with M/M, but it's not ideal. I don't mind losing the USB key, I don't quite see the need with an available SD slot. DFU you still need to hook up to a PC and run some STM tool for flashing right? It just runs some hard-coded bootloader in ROM if I recall, I don't think you can put in a custom routine to load off a USB flash disk and copy over firmware.bin for example. So in that scenario you'd require the user to buy a USB M/M cable just for flashing, and I'd just as re-use their own bootloader at that point.

[LoialOtter]

DFU under linux is just a normal package - it's not just ST as well as DFU is a a standard for uploading firmware to USB devices.

For me USB is pretty important as it gives the command prompt for python. My plan is to make a lowlevel driver set which will get the steppers and temperature control reliably running then use python to do the motion planning and g-code to control interface. I want to go this route mostly due to wanting to have a platform that's super easy to get working with unusual hardware. As an added benefit, micropython also supports SD cards and can load it's code off there or the 4MB flash that's also on the board.

[xC0000005]

Does anyone have a lerdge-x board they've already reset the bootloader on? I think I've managed to fully decrypt the existing one (and I'm fairly certain the firmware's completely decrypted now), but obviously once I flip the bit to reset read protect and rewrite, I lose my encryption breaking ability

[mcheah]

They bothered encrypting the firmware? That's a next step. I'm planning on running third party firmware anyway if no one else steps up i can take the risk. Is the bootloader encrypted too?

[mcheah]

If you can decrypt the firmware, then the easier test may be to encrypt your own firmware. Write a blinky program, encrypt and upload it and if it works then you know you've got the right encryption scheme. That way you don't have to touch the bootloader in case something goes wrong. You can then read out the bootloader bit by bit and compare against the bootloader binaries.

[xC0000005]

I can. In the files section for my hackaday project, I attached a python script that decrypts whatever you hand it. Odds are, there’s a simple way to do this that doesn’t involve a table of all 256 byte values, but since I extracted it as a byte table, I’m leaving it as such for now).

https://hackaday.io/project/162592-lerdge-3d-printer-mainboard-hacking https://hackaday.io/project/162592-lerdge-3d-printer-mainboard-hacking

I may try and write a blink program later today once I extend the decrypt script to an encrypt script. The firmware seems to load at 0x8060000,. The stock bootloader is only 64k (61, but it has to end on a page boundary), so I have no idea what it’s doing with all that other space. My best guess is that all the UI bitmaps are crammed into ROM in that area.

On Dec 5, 2018, at 6:12 AM, mcheah notifications@github.com wrote:

If you can decrypt the firmware, then the easier test may be to encrypt your own firmware. Write a blinky program, encrypt and upload it and if it works then you know you've got the right encryption scheme. That way you don't have to touch the bootloader in case something goes wrong. You can then read out the bootloader bit by bit and compare against the bootloader binaries.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-444498530, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWpelhPGytuan8eLVQ6LEVHhhVRLks5u19RpgaJpZM4YNGqo.

[mcheah]

Very interesting, I will read through all the details when I have more time. I had briefly tried altering the image files by appending zero's the the end of all the binaries. It seemed to me that they didn't do a checksum or anything since the modified firmwares loaded just fine. I was hoping to crash the processor by causing it to write beyond the flash ROM memory space (and thus determine the firmware memory address), but it seems they truncate or ignore the extended image.

[xC0000005]

The bootloader must be a second stage one. It loads at 0x08010000. Haven’t quite found the actual encryption code, but I will. I’m certain the decryption is working now, but I don’t know what lies before the bootloader, or after it yet.

On Dec 5, 2018, at 8:37 AM, mcheah notifications@github.com wrote:

Very interesting, I will read through all the details when I have more time. I had briefly tried altering the image files by appending zero's the the end of all the binaries. It seemed to me that they didn't do a checksum or anything since the modified firmwares loaded just fine. I was hoping to crash the processor by causing it to write beyond the flash ROM memory space (and thus determine the firmware memory address), but it seems they truncate or ignore the extended image.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-444552579, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcf2Op_x0lZtyPWeaB06m-1_vTlgxks5u1_ZNgaJpZM4YNGqo.

[LoialOtter]

As soon as you're able to make a payload it'll be really easy to dump the whole image. Code running from flash has 100% access to flash for obvious reasons.

I have one board that I haven't erased and a second one I have - let me know what's needed to test.

[xC0000005]

Yes, I extracted the malyan bootloader the same way. On the board you erased, you can TRY loading this at the base of flash. If it works, you can then theoretically re-flash to the Lerdge firmware.

On Dec 5, 2018, at 6:57 PM, Loial Otter notifications@github.com wrote:

As soon as you're able to make a payload it'll be really easy to dump the whole image. Code running from flash has 100% access to flash for obvious reasons.

I have one board that I haven't erased and a second one I have - let me know what's needed to test.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-444730878, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcX_44O13qnB3jA8W7xLdguYcVxAzks5u2IeugaJpZM4YNGqo.

[xC0000005]

decrytpedbootloader.bin.zip Let's try this again. Now you should get it.

[xC0000005]

After checking again, the decrypted bootloader definitely starts at 0x10000, so there's something earlier, I just don't know what.

[LoialOtter]

the ST parts have an interesting problem when it comes to bootloaders - the first 4k is not rewritable if readout protection is enabled. This problem generally means a dual bootloader setup. The first bootloader may be the same but compiled to operate in this range (and they may have found out about this after shipping like I did).

My solution when I found out about this was to replace a call that happened outside this 4k limit in the original bootloader with a reconfigure and restart from a 4k image. All later releases of that hardware I instead included a 4k first boot that simply reconfigured the chip for operation at 4k and restarted there.

[xC0000005]

It’s certainly possible. If I can ever get a payload to run, I can dump everything. The firmware and bootloader do NOT start the way ST’s normal code does. Neither load the SP, there is no timer configuration, so the bootloader isn’t just there to decrypt and start - it’s integral to setup. Furthermore, it’s clear there’s at least three “initial” stack pointer values in the RAM - all lerdge firmware, including the -s, use only the lower half of RAM, while the second stage bootloader sets its initial SP to near the top.

Right now I cloned a variant and put a function to set LEDs called straight off the resetHandler, but it can’t make any calls yet, since i don’t know the state of the peripherals. I need to make simple math based LED flasher like the turnOnFan function I used on the M200s to diagnose.

On Dec 6, 2018, at 6:39 PM, Loial Otter notifications@github.com wrote:

the ST parts have an interesting problem when it comes to bootloaders - the first 4k is not rewritable if readout protection is enabled. This problem generally means a dual bootloader setup. The first bootloader may be the same but compiled to operate in this range (and they may have found out about this after shipping like I did).

My solution when I found out about this was to replace a call that happened outside this 4k limit in the original bootloader with a reconfigure and restart from a 4k image. All later releases of that hardware I instead included a 4k first boot that simply reconfigured the chip for operation at 4k and restarted there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-445103198, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppccNis36ZSdUJHxhh3wytL-sQIyAaks5u2dTSgaJpZM4YNGqo.

[mcheah]

I think I've got a project written for a similar STM32F4 processor to do the memory readout if that's helpful here. I think it should be pretty easy to port over to F407 from the F446. You'll just need to expose one of the UART interfaces. The F07 projects are the cortex M0 version I adapted for the MPMD.

https://github.com/mcheah/stm32MemStream/tree/master/stm32MemStream

You'll need systemworkbench for stm32, and will need to update the pinmappings, but might give you a head start. I might have some time this weekend to give it a try myself now that we know the method to encrypt/load arbitrary code. There's a project called uBlinky that's a barebones blinky program as well.

FYI, I believe the UART/SWD pins are brought out to the 1mm header pins next to the USB port, so you should be able to do most of this with no soldering.

[xC0000005]

You are correct - the SWD pins are easily accessed via the expansion port where the network adapter plugs in. At least one UART is in the 6 pin header - an ESP8266 plugs in there for wifi printing, and that interface is purely serial. I’m going to keep hacking until I have some control of the system. Then, the simplest option is to write a “obliterate everything” function that resets all timers, systick, callbacks, DMA, interrrupts, etc, and then runs as if system reset had just occurred. But until I can blink an LED ont he board, I’m just working on it. I uploaded a new version to hackaday.io http://hackaday.io/ that supports encrypting instead of just decrypting, now.

On Dec 6, 2018, at 7:02 PM, mcheah notifications@github.com wrote:

I think I've got a project written for a similar STM32F4 processor to do the memory readout if that's helpful here. I think it should be pretty easy to port over to F407 from the F446. You'll just need to expose one of the UART interfaces. The F07 projects are the cortex M0 version I adapted for the MPMD.

https://github.com/mcheah/stm32MemStream/tree/master/stm32MemStream https://github.com/mcheah/stm32MemStream/tree/master/stm32MemStream You'll need systemworkbench for stm32, and will need to update the pinmappings, but might give you a head start. I might have some time this weekend to give it a try myself now that we know the method to encrypt/load arbitrary code. There's a project called uBlinky that's a barebones blinky program as well.

FYI, I believe the UART/SWD pins are brought out to the 1mm header pins next to the USB port, so you should be able to do most of this with no soldering.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-445107020, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcf1gKIO_hVT-d8dDQHR7CMWzSB5wks5u2dorgaJpZM4YNGqo.

[mcheah]

Easiest would be to just disable interrupts, no?

[xC0000005]

I have learned the hard way from the M200 that doing that alone does NOT set the system up for configuration properly - if systick isn’t running wihtout any crap left over from the bootloader at pre-main, static initializers with delays will hang. Of course, I’ll try just disabling interrupts first.

On Dec 6, 2018, at 7:09 PM, mcheah notifications@github.com wrote:

Easiest would be to just disable interrupts, no?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-445108197, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcaNSYFog2fSIRRiYuvbJCIPgAxuaks5u2dvegaJpZM4YNGqo.

[xC0000005]

Sort of basic question - which LEDs are PC7 and PC6 connected to? And is it writing high to them that turns them on or low?

[xC0000005]

Some updates (this isn't what I was looking for, but the things you find when you go looking...): The LCD is addressed in FSMC mode. The control register is at 0x60000000, the data register at 0x60020000. I can't tell what the controller is based on the init sequence, but if nothing else, you can simply string the commands together and it will work.

I also attached a list of the pins that are configured for FMSC (that's the alternate function 0xC).

[xC0000005]

Also, I have zero idea now where anything is loading. I have the DLion source now thanks to someone on hackaday - DLion is the ancester of the lerdge board - none of the encryption, but you can see the structure and nod and say "I can see how they got here from there." Particularly when you look at the font update/SPI Flash code it should be familiiar.

The code is built with Keil, and Keil has a habit of sticking the vector table near the end. If I load the firmware at 0x10000, the vector tables correctly resolve to a set of infinite loops (which is usually the best way to track down an unknown arm vector table). The problem is, they also make some sense at 0x60000. The bootloader does NOT at 0x0000.

I'm thinking my goal here is shifting - this bootloader is a pain in the ass to work with. What I want to do is get in and dump out the base image so people can DFU back, then we'll drop something sane on for everything else. Also, once we have the core image, it should be possible to disable flash protect and set it up. Warning - the bootloader will re-enable flash protection if it's disabled, during the update sequence.

[mcheah]

If you can isolate where the bootloader is setting the security bits, presumably you could edit the binary to NOT that no? Or take a different route and just provide your own bootloader instead of the stock one.

What program are you using to disassemble the decrypted binary? How are you getting the symbols for the function names? Is that from the DLion source?

[carl1961]

Here is a Dlion manual, I downloaded before the site was took down, on page 24 starts where is shows how to burn the boot-loader, maybe it has some clues for you. I am so new to this so as of right now I have no clue what needs to be. Dillon motherboard manual-ProV3.2 (1).pdf

also Dlion Marlin GitHub of a older version may be useless

https://github.com/Pomise/Dlion-Stm32-3D

[xC0000005]

Program I'm using - BinaryNinja. Function names were added by myself, and the name is almost always evolving. Delay was 'Mess with Sys Clock." Followed by "Wait for SysClock" and then when I looked at how it was used, "Delay." The LCD code, I looked at ST's app note on interfacing with TFT LCDs and saw it used the FSMC and said "Hey, that looks familiar." If anyone has a board which they can load code on (erased), check the device ID - that will probably give us a clue to the controller for the LCD. Yes, I could disable the function to re-enable protection. It's interesting that they thought of so many contingencies.

[xC0000005]

There's actually two different ways to address the LCD in terms of initialization - this is likely how the bootloader operations in both graphic modes. In the second, it does NOT send the wakeup sequence, but in both cases, reads the device and manufacturer ID.

I'd love to know what it reports. I may attempt to read them out via GDB (I'm not sure it is supposed to work, but we'll see). The Lerdge code expects the manufacturer bytes to add up to 0x55 (yeah, it's odd).

[xC0000005]

If you own a lerdge board you've erased, I have uploaded two files to my hacking project. One is what I see at the first 64k, the second is the decrypted bootloader update, which I swear looks like it would run at 0x10000.

You can try and use the base bootloader. If flashed at the base of flash, you should recover the ability to reset to lerdge's released firmware. Files here:

https://hackaday.io/project/162592-lerdge-3d-printer-mainboard-hacking

[xC0000005]

@LoialOtter, have you actually succeeded running code on the lerdge you reset? If so, what clock configuration did you use? I've figured out that my code isn't executing because I never exit from the system clock config. Since I cloned my variant from a discovery board, it's highly likely it's wrong. (alternately, if anyone knows the external crystal frequency on a lerdgex, that would help, too.)

[LoialOtter]

https://github.com/LoialOtter/micropython runs fine on the board. I configured it with a 25MHz external oscillator. Check under ports/stm32/boards/LERDGE_X/stm32f4xx_hal_conf.h for hardware config.

[xC0000005]

Thank you. I’ll pay attention to how it’s configuring the clocks. The arduino code is failing to pass clock intiialization, probably because of something I did wrong. If you get a chance, could you test the decrypted bootloader (lerdgebasebootloader.bin) and see if it then allows you to reflash to lerdge’s official firmware?

On Dec 11, 2018, at 6:45 AM, Loial Otter notifications@github.com wrote:

https://github.com/LoialOtter/micropython https://github.com/LoialOtter/micropython runs fine on the board. I configured it with a 25MHz external oscillator. Check under ports/stm32/boards/LERDGE_X/stm32f4xx_hal_conf.h for hardware config.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-446227443, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWYNwxpU11khcuDRTsHJFgV8aTe-ks5u38UfgaJpZM4YNGqo.

[xC0000005]

Finally got control of the board by not re-initializing the HSE (or frankly, any of the clocks - ST officially warns against messing with the HSI once it's up and running, and they aren't kidding - you can kill SWD).

https://twitter.com/AuthorJCNelson/status/1072719345078292481

Next up, getting my board variant cleaned up and posted to my github.

[carl1961]

Awesome work! @LoialOtter and @xC0000005 wish i was more knowledgeable to help. how would i properly go about preparing a x board to test? I have all the software and tools I think to do testing.

[xC0000005]

I have zero idea how to put the board into DFU mode. My next steps are going to be to build a pins.h file for the lerdge x, and maybe build a "bootloader dump" sketch. Progress on Marlin will be slow since I need USB support. That's a 1.5 feature, and the ST developer has said a PR is coming soon for it, but a lot of this is going to be "huh, we need PWM on this pin, so can't use that timer" or the like. @LoialOtter, for micropython, to get it to run with the default loader, all you should have to do is change the VECT_TABLE_ADDR (and linker script, of course) to a start offset of +0x10000, and comment out the clock config/stub it with a blank, then encrypt the resulting bin with the lerdgeencrypt2.py script. I'm not saying you have to do this. In fact, for Marlin, I'd expect that there will be a couple of different options, one for people who just want to slap it on and try, and one for people who aren't going back, and who upgrade their bootloader to something that doesn't eat up the SPI RAM with fonts Marlin won't use. Edit to add "and encrypt" for the how to use.

[mcheah]

I'd guess DFU mode is that button next to the USB/expansion port. If you hold it down while powering up it should show up in windows (you still need a USB A to A male/male cable) device manager. If I were you I'd use the standalone UART port accessible through the expansion connector for now, and just hook up an FTDI adapter for now. I'd also consider ditching the hardware PWM altogether and just doing it through software. The only thing that needs microsecond tick rates is the stepper ISR, and frankly at 168MHz, you could jankily do it without a hardware timer. There's kind of the "right way" to be developing for this board, and there's the "janky, but kind of works" way to get things running as a proof of concept. I'm considering making a custom board through oshpark to add a microUSB, and JTAG ribbon connector to the 0.05" expansion port to make developing easier. Does anyone know what is stored on the two external memory chips? I think there's a 4M SPI flash and a smaller EEPROM. Maybe that's the UI assets?

[xC0000005]

The UI Asssets are almost certainly going to SPI flash. When it fails to load the UI during bootup it logs an SPI error. There’s a picture on my hackaday project of where the two SWD pins are. If you have the USB B adapter, you could solder to those pins instead, and get the ability to remove your leads if needed.

On Dec 12, 2018, at 10:38 AM, mcheah notifications@github.com wrote:

I'd guess DFU mode is that button next to the USB/expansion port. If you hold it down while powering up it should show up in windows (you still need a USB A to A male/male cable) device manager. If I were you I'd use the standalone UART port accessible through the expansion connector for now, and just hook up an FTDI adapter for now. I'd also consider ditching the hardware PWM altogether and just doing it through software. The only thing that needs microsecond tick rates is the stepper ISR, and frankly at 168MHz, you could jankily do it without a hardware timer. There's kind of the "right way" to be developing for this board, and there's the "janky, but kind of works" way to get things running as a proof of concept. I'm considering making a custom board through oshpark to add a microUSB, and JTAG ribbon connector to the 0.05" expansion port to make developing easier. Does anyone know what is stored on the two external memory chips? I think there's a 4M SPI flash and a smaller EEPROM. Maybe that's the UI assets?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-446696024, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcc1_Shm2t8sWnWS5YrMrzIxEJ-KTks5u4U0lgaJpZM4YNGqo.

[mcheah]

That makes sense, explains why there's a separate UI .bin file. Yeah, they're certainly accessible, I just find when I'm screwing around with a circuit with flying wires for an extended period of time you'll eventually rip something off. Nothing more frustrating than chasing down an intermittent bug when the SWD dips out randomly as well. So you took the plunge and nuked the security bits now? Or uploading encrypted binaries still?

[xC0000005]

Still uploading encrypted binaries for now. Once I get the dump sketch working, I’ll make a backup of CCRAM (it’s writing something there and actually interacting with it), SPI flash, and most of the flash space. That gives us a 100% “go back” mode for users.

Then I’m going to reset and find a bootloader that doesn’t suck. I want to have the variant work in two ways: Mode 1 - for users to “try” - encrypts, limited resources, etc. Mode 2 - “Screw this, I’m moving.” - New bootloader, use SPI flash for whatever. Also, t’s nice to note that the ESP8266 webUI just slots tot he expansion port and works. You configure it as the second host and it feeds gcode.

On Dec 12, 2018, at 10:46 AM, mcheah notifications@github.com wrote:

That makes sense, explains why there's a separate UI .bin file. Yeah, they're certainly accessible, I just find when I'm screwing around with a circuit with flying wires for an extended period of time you'll eventually rip something off. Nothing more frustrating than chasing down an intermittent bug when the SWD dips out randomly as well. So you took the plunge and nuked the security bits now? Or uploading encrypted binaries still?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-446698718, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcVJ6rjzynOFKgpbFXGzBAb_6mOQ0ks5u4U8PgaJpZM4YNGqo.

[mcheah]

Gotcha, keep me updated. I should have a lot more time to mess around with this for the next few weeks or so. In my experience, most people won't bother installing anything unless it's super easy mode to install. This of course gets way more complicated when end users need to compile to support different printer hardware. So I'd say Mode 1 is pretty critical because people without coding experience eventually muck things up without reading instructions, blame the new software, and want to go back to stock. I think best case scenario is if you could compile and upload from Arduino software like everybody expects for typical RAMPS boards.

[xC0000005]

Agree. The first thing out of the gate has to be something that “just works” even if it works in limited scenarios. It’s unlikely the LCD, for instance, will work at first. Oddly enough, since it costs me nothing, the secondary serial/Web printing will work straight out of the box. I know how it’s reading the touch screen as well, now. It looks like the touch screen has an pin it raises when there’s a touch. this appears to trigger a read to RAM of the X/Y, and then from there, it decides if the rectangle is within a menu border.

On Dec 12, 2018, at 10:57 AM, mcheah notifications@github.com wrote:

Gotcha, keep me updated. I should have a lot more time to mess around with this for the next few weeks or so. In my experience, most people won't bother installing anything unless it's super easy mode to install. This of course gets way more complicated when end users need to compile to support different printer hardware. So I'd say Mode 1 is pretty critical because people without coding experience eventually muck things up without reading instructions, blame the new software, and want to go back to stock. I think best case scenario is if you could compile and upload from Arduino software like everybody expects for typical RAMPS boards.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-446702185, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcZA3dcfP6bR5QPoMyRvYsE8saG7Oks5u4VGAgaJpZM4YNGqo.

[mcheah]

LCD I feel will probably be a challenge unless somebody has already written some stuff for Marlin already. For my money I think finding a way to hook up a standard reprapLCD or even a panel Due will probably be a better option than redoing the entire driver/UI of the bundled touch screen. Interestingly though, nobody bothered using my mini delta Marlin port until I added in the LCD support (thanks to your malyanlcd code!). So my assumption that all tinkerers are already running pronterface/repetier/octoprint was not really true.

As for the ESP8266 web server, I'm kind of starting to lean away from these kind of scenarios. Maybe it's gotten better with Marlin 2.0, but I felt that you'd get stuttering when streaming g-code regardless of how fast the host is, especially for deltas. Sending line-by-line in ASCII with acks does not lend to high throughput and low latency. So the ideal scenario for me would be to stream the whole file at once, save it to the SD card, and then run off of that. Kind of an off-topic rant, honestly just curious if anyone else has tackled this issue.

[xC0000005]

There’s someone who’s worked out how to get the MKS-ROBIN working. All of these, including DLION, are built off of ST’s “Interfaceing LCD with STM32Fx processors using FSMC” app note. So, we’ll build off their work, using the lerdge specific init sequence.

On Dec 12, 2018, at 11:15 AM, mcheah notifications@github.com wrote:

LCD I feel will probably be a challenge unless somebody has already written some stuff for Marlin already. For my money I think finding a way to hook up a standard reprapLCD or even a panel Due will probably be a better option than redoing the entire driver/UI of the bundled touch screen. Interestingly though, nobody bothered using my mini delta Marlin port until I added in the LCD support (thanks to your malyanlcd code!). So my assumption that all tinkerers are already running pronterface/repetier/octoprint was not really true. As for the ESP8266 web server, I'm kind of starting to lean away from these kind of scenarios. Maybe it's gotten better with Marlin 2.0, but I felt that you'd get stuttering when streaming g-code regardless of how fast the host is, especially for deltas. Sending line-by-line in ASCII with acks does not lend to high throughput and low latency. So the ideal scenario for me would be to stream the whole file at once, save it to the SD card, and then run off of that. Kind of an off-topic rant, honestly just curious if anyone else has tackled this issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LoialOtter/Open-Lerdge-X/issues/1#issuecomment-446708963, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcRdmIA-B6jZ2XfRDWG8PPE6Ndsibks5u4VXagaJpZM4YNGqo.

[mcheah]

In the process of mapping out the expansion connector, I intend to make a little adapter board for ST-link. Can either of you confirm that this matches what you've seen? One interesting thing I've noticed is that there's only one hardware UART exposed on this connector, which I presume is connected to the CH340 chip on the USB board. But they also have some interface to the ESP8266 module in that riser connector. @xC0000005, can you confirm the pinout of the ESP8266 module? This seems to imply that either the USB connection or the ESP is using software serial for communication.

[mcheah]

Re: DFU Mode I was wrong about the button in the lower left corner of the board, it's a reset button, not boot0 as I thought. It looks like boot0 is not accessible by a connector pin. There's a 10k resistor to ground as marked below, if you want to enable DFU loading you'll have to momentarily short it to 3.3 during powerup, probably not a great user accessible option.

[LoialOtter]

sorry I haven't been able to help at all with testing. My dev setup for this project has been disassembled for a bit and I've been swamped by bringup of a new FPGA at work (look up chronos1.4). As soon as I get a chance I'll get it set up again.

[xC0000005]

It's all good. I got the lerdge K board today from Carl. It currently crashes my mac when I plug it in, but that's because OSX and the CH340 drivers don't get along well. I'll be working on a universal bootloader dumping sketch next - I need to make this easy and near automatic, and then I'll dump the loader from the Lerdge K. Oddly enough, the lerdge-x does NOT crash the mac.

I compiled Marlin with a pins definition for the X, but it is failing, and I don't know why yet. There's so many moving parts right now it's entirely conceivable that it's a timer initialization issue, or USB, or something else. On my marlin fork, there's now a lerdge branch. This has the USB pull request merged into it. I'm hoping in the next week to be able to get something basic running. Not necessarily tuned or featureful, just "not crashing" would be a good start. Anyone who wants to start working on a pins_LERDGE_K file, feel free. You can always dump it off on me and I'll merge it in.