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.

[jmz52]

And it is looks like the cardSize() method is not being used after all, so only three methods are needed.

[xC0000005]

I’d actually looked at the block interface and thought about modifying it there. I’ll give it a spin on the unified HAL (which is where, eventually, most stuff will land). Right now, STM32DUINO is slightly ahead in terms of features, and will stay that way until the 1.5 release gives USB to most of the boards.

On Dec 31, 2018, at 1:36 PM, jmz52 notifications@github.com wrote:

And it is looks like the cardSize() method is not being used after all, so only three methods are needed.

— 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-450692495, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppca7HzALPoslgYM6kKgZIUNrdkYHSks5u-oNrgaJpZM4YNGqo.

[jmz52]

PR for SDIO support submitted. https://github.com/MarlinFirmware/Marlin/pull/12782

I did not find a good place to add a dependency, so both defines are still needed to make it work. #define SDSUPPORT #define SDIO_SUPPORT

[mcheah]

@xC0000005, Some updates, I managed to dump out the bootloader over UART with my own app. The binaries don't match your lerdge x bootloader binary, but I suspect this is because I updated my bootloader to V1.0.4 as provided by Lerdge before starting this endeavor. Interestingly it matches the Lerdge K bootloader you posted fairly well, but not exactly. It says in plaintext in the binary the version number.

By comparing against the bootloader binary provided by lerdge, it provides some interesting insights. It seems that 0x07D4 - 0xB020 maps out to 0x0000 to 0xA84C. Beyond 0xA84C I get bytes filled with 0xFF's. It's unclear where/what the rest of the bootloader binary provided by lerdge does. My suspicion is that it gets loaded onto SDRAM, or perhaps some of the assets get loaded onto the SPI flash. But for the purposes of restoring the device to stock via SWDIO, it probably doesn't matter, we have our own backups now. Another nice thing I confirmed is that the entire application binary gets loaded directly to 0x80010000 as is, which is really the more important thing for running custom code.

The next steps for me are to nuke the security bits and start poking around at the register settings. I need to adapt the drivers for my custom stm32 Marlin fork. Hopefully this will help flesh out some of the platform specific issues so that they can be integrated into the Marlin 2.0 port.

lerdgexboot_1.0.4.zip

[xC0000005]

Fantastic. Judging from my reverse engineering of the bootloader, assets get loaded primarily to SDRAM. There’s FATFS support for SPI, and I think they use that. My time on tis project is going to be limited due to day-job commitments for a bit. The SDIO hal abstraction PR is the right way to incorporate it, I just can’t get the raw SDIO block commands to work at the moment. If you flash bootloader and firmware together I don’t believe it re-protects flash. I’ll upload my lerdge reset script to Hackaday for you shortly.

On Jan 2, 2019, at 11:54 PM, mcheah notifications@github.com wrote:

@xC0000005 https://github.com/xC0000005, Some updates, I managed to dump out the bootloader over UART with my own app. The binaries don't match your lerdge x bootloader binary, but I suspect this is because I updated my bootloader to V1.0.4 http://www.lerdge.com/Private/Files/20181016095217426%E2%88%AELerdge_X_Bootloader.zip as provided by Lerdge before starting this endeavor. Interestingly it matches the Lerdge K bootloader you posted https://cdn.hackaday.io/files/1625926956336128/lergdekloader.bin fairly well, but not exactly. It says in plaintext in the binary the version number.

By comparing against the bootloader binary provided by lerdge, it provides some interesting insights. It seems that 0x07D4 - 0xB020 maps out to 0x0000 to 0xA84C. Beyond 0xA84C I get bytes filled with 0xFF's. It's unclear where/what the rest of the bootloader binary provided by lerdge does. My suspicion is that it gets loaded onto SDRAM, or perhaps some of the assets get loaded onto the SPI flash. But for the purposes of restoring the device to stock via SWDIO, it probably doesn't matter, we have our own backups now. Another nice thing I confirmed is that the entire application binary gets loaded directly to 0x80010000 as is, which is really the more important thing for running custom code.

The next steps for me are to nuke the security bits and start poking around at the register settings. I need to adapt the drivers for my custom stm32 Marlin fork. Hopefully this will help flesh out some of the platform specific issues so that they can be integrated into the Marlin 2.0 port.

— 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-451074499, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcbv-n-kTEYRrUiz5tUJdzkSKPsHoks5u_bccgaJpZM4YNGqo.

[xC0000005]

I uploaded my opencd cfg I use to reset the lerdge to Hackaday. Also @dzenik has managed to init and fill the LCD(!).

On Jan 2, 2019, at 11:54 PM, mcheah notifications@github.com wrote:

@xC0000005 https://github.com/xC0000005, Some updates, I managed to dump out the bootloader over UART with my own app. The binaries don't match your lerdge x bootloader binary, but I suspect this is because I updated my bootloader to V1.0.4 http://www.lerdge.com/Private/Files/20181016095217426%E2%88%AELerdge_X_Bootloader.zip as provided by Lerdge before starting this endeavor. Interestingly it matches the Lerdge K bootloader you posted https://cdn.hackaday.io/files/1625926956336128/lergdekloader.bin fairly well, but not exactly. It says in plaintext in the binary the version number.

By comparing against the bootloader binary provided by lerdge, it provides some interesting insights. It seems that 0x07D4 - 0xB020 maps out to 0x0000 to 0xA84C. Beyond 0xA84C I get bytes filled with 0xFF's. It's unclear where/what the rest of the bootloader binary provided by lerdge does. My suspicion is that it gets loaded onto SDRAM, or perhaps some of the assets get loaded onto the SPI flash. But for the purposes of restoring the device to stock via SWDIO, it probably doesn't matter, we have our own backups now. Another nice thing I confirmed is that the entire application binary gets loaded directly to 0x80010000 as is, which is really the more important thing for running custom code.

The next steps for me are to nuke the security bits and start poking around at the register settings. I need to adapt the drivers for my custom stm32 Marlin fork. Hopefully this will help flesh out some of the platform specific issues so that they can be integrated into the Marlin 2.0 port.

— 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-451074499, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcbv-n-kTEYRrUiz5tUJdzkSKPsHoks5u_bccgaJpZM4YNGqo.

[mcheah]

I'm using the stm32-utility for windows, I think it's just a GUI-friendly way of doing the openocd stuff. I believe the bootloader (or at least on my system) re-enables the option bytes regardless of whether it is flashing a new firmware. I tried patching the bootloader binary by replacing the 0x08192A3B and 0x4C5D6E7F flash key constants with 0x00000000, which correctly prevents the option bytes from being overwritten, but then the bootloader hangs in an infinite loop, either because of a fault when attempting to write to the flash option bytes or a status check to make sure the bits were set.

Not quite as easy as I was hoping. I may try my hand at some disassembly. In theory once you nuke the security bits and reflash the micro you should be able to single-step to see where those memory accesses take place and remove those instructions. The easier strategy is probably to just dump the peripheral registers and start developing without the bootloader for now.

[xC0000005]

I’ve done exactly this, and the answer is, I can’t find a place where it sets read protection level 2 (0x55). Here’s the check for whether or not it’s unprotected:

I’m not saying it doesn’t exist, just that I can’t find it yet. Hang on, going to run this through retdec.

On Jan 3, 2019, at 9:27 AM, mcheah notifications@github.com wrote:

I'm using the stm32-utility for windows, I think it's just a GUI-friendly way of doing the openocd stuff. I believe the bootloader (or at least on my system) re-enables the option bytes regardless of whether it is flashing a new firmware. I tried patching the bootloader binary by replacing the 0x08192A3B and 0x4C5D6E7F flash key constants with 0x00000000, which correctly prevents the option bytes from being overwritten, but then the bootloader hangs in an infinite loop, either because of a fault when attempting to write to the flash option bytes or a status check to make sure the bits were set.

Not quite as easy as I was hoping. I may try my hand at some disassembly. In theory once you nuke the security bits and reflash the micro you should be able to single-step to see where those memory accesses take place and remove those instructions. The easier strategy is probably to just dump the peripheral registers and start developing without the bootloader for now.

— 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-451215869, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcRJcdlXboDknwlxfLDF0SNTT5ADdks5u_j2JgaJpZM4YNGqo.

[xC0000005]

I can’t get ret-dec to run on my mac right now. If you want to download it and run it, tell me where it’s reseting the option bytes and I’ll use BinaryNinja to blast it (or you can). https://github.com/avast-tl/retdec https://github.com/avast-tl/retdec

On Jan 3, 2019, at 9:27 AM, mcheah notifications@github.com wrote:

I'm using the stm32-utility for windows, I think it's just a GUI-friendly way of doing the openocd stuff. I believe the bootloader (or at least on my system) re-enables the option bytes regardless of whether it is flashing a new firmware. I tried patching the bootloader binary by replacing the 0x08192A3B and 0x4C5D6E7F flash key constants with 0x00000000, which correctly prevents the option bytes from being overwritten, but then the bootloader hangs in an infinite loop, either because of a fault when attempting to write to the flash option bytes or a status check to make sure the bits were set.

Not quite as easy as I was hoping. I may try my hand at some disassembly. In theory once you nuke the security bits and reflash the micro you should be able to single-step to see where those memory accesses take place and remove those instructions. The easier strategy is probably to just dump the peripheral registers and start developing without the bootloader for now.

— 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-451215869, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcRJcdlXboDknwlxfLDF0SNTT5ADdks5u_j2JgaJpZM4YNGqo.

[Dzenik]

I've uploaded preliminary code to https://github.com/jmz52/Marlin/tree/STM32F1-SDIO-support-rc0

Marlin/src/sd/SdVolume.h: With "SDIO_SUPPORT" defined the #include "Sd2Card.h" is replaced by #include "Sd2Card_sdio.h" Sd2Card class is redefined with the only 4 methods used by Marlin - init, writeBlock, readBlock and cardSize(returns number of 512-bytes blocks)

These methods relies on HAL-specific functions to do actual work: bool SDIO_Init(void); bool SDIO_ReadBlock(uint32_t block, uint8_t dst); bool SDIO_WriteBlock(uint32_t block, const uint8_t src); uint32_t SDIO_GetCardSize(void);

You need two defines to make it work (will be changed to one define)

define SDSUPPORT

define SDIO_SUPPORT

Please note that stm32duino uses different SDIO registers structure than CubeMX (STM32 HAL libraries). stm32duino defines RESP as an array when CubeMX defines it as four uint32_t variables.

What tool are you using? I revised STM32duino and stevstrong/Arduino_STM32 but did not find the right one to compile. Specify where I can download the correct one so that your code is compiled.

[xC0000005]

I’ve managed to get a file list using @jmz52’s SDIO abstraction method. I’ve got a ton of niggling things to fix and some code to consolidate, but it should be possible to do a test print soon.

On Jan 3, 2019, at 10:09 AM, Dzenik notifications@github.com wrote:

I've uploaded preliminary code to https://github.com/jmz52/Marlin/tree/STM32F1-SDIO-support-rc0 https://github.com/jmz52/Marlin/tree/STM32F1-SDIO-support-rc0 Marlin/src/sd/SdVolume.h: With "SDIO_SUPPORT" defined the #include "Sd2Card.h" is replaced by #include "Sd2Card_sdio.h" Sd2Card class is redefined with the only 4 methods used by Marlin - init, writeBlock, readBlock and cardSize(returns number of 512-bytes blocks)

These methods relies on HAL-specific functions to do actual work: bool SDIO_Init(void); bool SDIO_ReadBlock(uint32_t block, uint8_t dst); bool SDIO_WriteBlock(uint32_t block, const uint8_t src); uint32_t SDIO_GetCardSize(void);

You need two defines to make it work (will be changed to one define)

define SDSUPPORT

define SDIO_SUPPORT

Please note that stm32duino uses different SDIO registers structure than CubeMX (STM32 HAL libraries). stm32duino defines RESP as an array when CubeMX defines it as four uint32_t variables.

What tool are you using? I revised STM32duino and stevstrong/Arduino_STM32 but did not find the right one to compile. Specify where I can download the correct one so that your code is compiled.

— 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-451228136, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppccvSIHdhceQooOUOHUTcm3GmEJSeks5u_kddgaJpZM4YNGqo.

[jmz52]

I am using PlatformIO with whatever packages it downloads by itself. You can find environment parameters in [env:mks_robin] section of platformio.ini file.

If I am reading the manifest file correctly current version is http://dl.platformio.org/packages/framework-arduinoststm32-3.10400.181126.tar.gz

[xC0000005]

So STM32DUINO’s F4 core. I’m building in the Arduino IDE against ST’s core right now, but the official core lacks some key features (USB) that will be required for it to catch up.

On Jan 3, 2019, at 10:32 AM, jmz52 notifications@github.com wrote:

I am using PlatformIO with whatever packages it downloads by itself. You can find environment parameters in [env:mks_robin] section of platformio.ini file.

If I am reading the manifest file correctly current version is http://dl.platformio.org/packages/framework-arduinoststm32-3.10400.181126.tar.gz http://dl.platformio.org/packages/framework-arduinoststm32-3.10400.181126.tar.gz — 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-451234803, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcfuXvcivZx88nZEXYon5N2QH8CLFks5u_kzYgaJpZM4YNGqo.

[mcheah]

I think I got it, I used cutter (radare2) to disassemble. There's a branch where it checks for 0xAA in the RDP option bytes, if you bypass it, it'll leave it alone.

lerdgexboot1.0.2.patched.zip

[xC0000005]

Try this.

On Jan 3, 2019, at 11:42 AM, mcheah notifications@github.com wrote:

I think I got it, I used cutter (radare2) to disassemble. There's a branch where it checks for 0xAA in the RDP option bytes, if you bypass it, it'll leave it alone. https://user-images.githubusercontent.com/7274015/50657878-aec88080-0f65-11e9-9623-295d180b8240.png https://user-images.githubusercontent.com/7274015/50657882-b1c37100-0f65-11e9-925c-225a29831763.png lerdgexboot1.0.2.patched.zip https://github.com/LoialOtter/Open-Lerdge-X/files/2725094/lerdgexboot1.0.2.patched.zip — 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-451254664, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcQyLjOFKvTaETR_8FTJsAF5sTt-Yks5u_l0QgaJpZM4YNGqo.

[mcheah]

It appears the application binary also resets the security bits. It's almost like they don't want us doing this. The same patch applies to the application binary. Also, for whatever reason just flashing the app at 0x08010000 would not start the program right. I had to re-load an encrypted binary through the SD bootloader in order to get the app to start up again. When I dumped the flash, it looks the same, so I suspect there are some UI assets on the SPI flash that got screwed up when I was mucking around with the bootloader.

Now I can debug and poke around the app firmware to better understand how they're utilizing the board. It looks like the bootloader does not use the HSE crystal, but the app firmware does. It also looks like the SDIO peripheral is not initialized in anyway, which would imply that they're bit-banging the SD card. It's possible that part of the reason the SDIO drivers aren't working is because they're not hooked up right or not all the necessary connections are hooked up. The only SPI interface initialized is SPI1, which is hooked up to the touch-screen.

lerdgexapp1.0.7.patched.zip

[xC0000005]

I have SDIO working now. The key was using the micropython timer init code.

On Jan 3, 2019, at 1:39 PM, mcheah notifications@github.com wrote:

It appears the application binary also resets the security bits. It's almost like they don't want us doing this. The same patch applies to the application binary. Also, for whatever reason just flashing the app at 0x08010000 would not start the program right. I had to re-load an encrypted binary through the SD bootloader in order to get the app to start up again. When I dumped the flash, it looks the same, so I suspect there are some UI assets on the SPI flash that got screwed up when I was mucking around with the bootloader.

Now I can debug and poke around the app firmware to better understand how they're utilizing the board. It looks like the bootloader does not use the HSE crystal, but the app firmware does. It also looks like the SDIO peripheral is not initialized in anyway, which would imply that they're bit-banging the SD card. It's possible that part of the reason the SDIO drivers aren't working is because they're not hooked up right or not all the necessary connections are hooked up. The only SPI interface initialized is SPI1, which is hooked up to the touch-screen.

lerdgexapp1.0.7.patched.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jmz52]

I've added three on-screen buttons to mimic functionality of encoder Robin does not have. Code is POC-quality and I do not plan to submit PR this feature in it's current state, but some bits might be used for proper UI. https://github.com/jmz52/Marlin/tree/MKS-Robin-Touch-POC Screenshot: https://ibb.co/p1Z9Q2K Please pay no attention to green color - it is just a "print completed" indication from PRINTER_EVENT_LEDS feature.

[jmz52]

What about USB-MSC? Is this something that could even be supported by Marlin?

Is not this is what "SHARED_SD_CARD" feature of HAL_LPC1768 is for?

[Dzenik]

I am using PlatformIO with whatever packages it downloads by itself. You can find environment parameters in [env:mks_robin] section of platformio.ini file.

If I am reading the manifest file correctly current version is http://dl.platformio.org/packages/framework-arduinoststm32-3.10400.181126.tar.gz

My PlatformIO not see HAL definition d:\1\marlin\marlin\src\hal\hal_stm32f4\watchdog_STM32F4.h:24:8: error: 'IWDG_HandleTypeDef' does not name a type although in the includes path they are present

[mcheah]

I got a bare-metal version of my stm32 Marlin port working on Lerdge X. Motion, heating, and mesh bed leveling is working as expected. Still have to add SD, LCD, USB, and EEPROM support, although with an FTDI board connected to UART it's probably not worth the effort to implement USB CDC. Not quite ready for prime time, but it's a good proof of concept.

https://github.com/mcheah/Marlin4MPMD/tree/lerdgex

[xC0000005]

PIO recently cut over support to the new ST Arduino core. You can use an older version of the platform to conftinue with STM32duino.

On Jan 4, 2019, at 6:27 PM, Dzenik notifications@github.com wrote:

I am using PlatformIO with whatever packages it downloads by itself. You can find environment parameters in [env:mks_robin] section of platformio.ini file.

If I am reading the manifest file correctly current version is http://dl.platformio.org/packages/framework-arduinoststm32-3.10400.181126.tar.gz http://dl.platformio.org/packages/framework-arduinoststm32-3.10400.181126.tar.gz My PlatformIO not see HAL definition d:\1\marlin\marlin\src\hal\hal_stm32f4\watchdog_STM32F4.h:24:8: error: 'IWDG_HandleTypeDef' does not name a type although in the includes path they are present

— 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-451620465, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcf-6vsQqRZFBzIflwdNz_A8XLxBIks5vAA1-gaJpZM4YNGqo.

[xC0000005]

The STM32SD library or BSP middleware works fine. I created a binary that dumps the bootloader now so I don’t have to dump it via UART.

On Jan 4, 2019, at 7:18 PM, mcheah notifications@github.com wrote:

I got a bare-metal version of my stm32 Marlin port working on Lerdge X. Motion, heating, and mesh bed leveling is working as expected. Still have to add SD, LCD, USB, and EEPROM support, although with an FTDI board connected to UART it's probably not worth the effort to implement USB CDC. Not quite ready for prime time, but it's a good proof of concept.

https://github.com/mcheah/Marlin4MPMD/tree/lerdgex https://github.com/mcheah/Marlin4MPMD/tree/lerdgex — 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-451623365, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWLP86AJXWqpuc1WtSKqZsvCxazeks5vABmGgaJpZM4YNGqo.

[xC0000005]

Also - for touch screen, https://platformio.org/lib/show/542/XPT2046_Touchscreen/ https://platformio.org/lib/show/542/XPT2046_Touchscreen/ or the BSP code seems to work.

On Jan 4, 2019, at 7:18 PM, mcheah notifications@github.com wrote:

I got a bare-metal version of my stm32 Marlin port working on Lerdge X. Motion, heating, and mesh bed leveling is working as expected. Still have to add SD, LCD, USB, and EEPROM support, although with an FTDI board connected to UART it's probably not worth the effort to implement USB CDC. Not quite ready for prime time, but it's a good proof of concept.

https://github.com/mcheah/Marlin4MPMD/tree/lerdgex https://github.com/mcheah/Marlin4MPMD/tree/lerdgex — 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-451623365, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWLP86AJXWqpuc1WtSKqZsvCxazeks5vABmGgaJpZM4YNGqo.

[jmz52]

What LCD controllers (or their IDs) are used on Lerdge boards? I've just found that one of older version of MKS Robin TFT uses ILI9328 controller with 16-bit data for writing registers. And with completely different commands codes and parameters. ILI9341 and ST7789 uses 8-bit data for writing registers, 16-bit data are only used when writing data to GRAM. And 16-bit data for writing registers does not fit well into writeByte() function of u8g communication layer. I am going to rework communication layer for TFT screens and I would like to check datasheets of controllers it will need to support someday.

[Dzenik]

My display is 0x04 0x04 0x04. Someone says that the HX8357 is installed, and someone that ST7789. But I am sure in one thing that data registers are 8-bit.

[Dzenik]

static const uint8_t LERDGE_init_sequence[] = { // 0x0404 U8G_ESC_ADR(0), 0x10, U8G_ESC_DLY(10), 0x01, U8G_ESC_DLY(100), U8G_ESC_DLY(100), 0x11, U8G_ESC_DLY(120), 0xF0, U8G_ESC_ADR(1), 0xC3, U8G_ESC_ADR(0), 0xF0, U8G_ESC_ADR(1), 0x96, U8G_ESC_ADR(0), 0x36, U8G_ESC_ADR(1), 0x28, U8G_ESC_ADR(0), 0x3A, U8G_ESC_ADR(1), 0x55, U8G_ESC_ADR(0), 0xB4, U8G_ESC_ADR(1), 0x01, U8G_ESC_ADR(0), 0xB7, U8G_ESC_ADR(1), 0xC6, U8G_ESC_ADR(0), 0xC1, U8G_ESC_ADR(1), 0x15, U8G_ESC_ADR(0), 0xC2, U8G_ESC_ADR(1), 0xAF, U8G_ESC_ADR(0), 0xC3, U8G_ESC_ADR(1), 0x09, U8G_ESC_ADR(0), 0xC5, U8G_ESC_ADR(1), 0x22, U8G_ESC_ADR(0), 0xC6, U8G_ESC_ADR(1), 0, U8G_ESC_ADR(0), 0xE8, U8G_ESC_ADR(1), 0x40, U8G_ESC_ADR(0), 0x8A, U8G_ESC_ADR(1), 0, 0, 0, 0x29, 0x19, 0xA5, 0x33, U8G_ESC_ADR(0), 0xE0, U8G_ESC_ADR(1), 0xF0, 0x04, 0x08, 0x09, 0x08, 0x15, 0x2F, 0x42, 0x46, 0x28, 0x15, 0x16, 0x29, 0x2D, U8G_ESC_ADR(0), 0xE1, U8G_ESC_ADR(1), 0xF0, 0x04, 0x09, 0x09, 0x08, 0x15, 0x2E, 0x46, 0x46, 0x28, 0x15, 0x15, 0x29, 0x2D, U8G_ESC_ADR(0), LCD_COLUMN, U8G_ESC_ADR(1), 0x00, 0x00, 0x01, 0x3F, U8G_ESC_ADR(0), LCD_ROW, U8G_ESC_ADR(1), 0x00, 0x00, 0x01, 0xDF, U8G_ESC_ADR(0), 0x20, U8G_ESC_ADR(0), 0x53, U8G_ESC_ADR(1), 0x24, U8G_ESC_ADR(0), 0xF0, U8G_ESC_ADR(1), 0x3C, U8G_ESC_ADR(0), 0xF0, U8G_ESC_ADR(1), 0x69, U8G_ESC_DLY(100), U8G_ESC_ADR(0), 0x29, LCD_WRITE_RAM, U8G_ESC_END };

[xC0000005]

I will try to get MCU friend running and see what it says about manufacturers and ID.

On Jan 5, 2019, at 2:26 PM, Dzenik notifications@github.com wrote:

static const uint8_t LERDGE_init_sequence[] = { // 0x0404 U8G_ESC_ADR(0), 0x10, U8G_ESC_DLY(10), 0x01, U8G_ESC_DLY(100), U8G_ESC_DLY(100), 0x11, U8G_ESC_DLY(120), 0xF0, U8G_ESC_ADR(1), 0xC3, U8G_ESC_ADR(0), 0xF0, U8G_ESC_ADR(1), 0x96, U8G_ESC_ADR(0), 0x36, U8G_ESC_ADR(1), 0x28, U8G_ESC_ADR(0), 0x3A, U8G_ESC_ADR(1), 0x55, U8G_ESC_ADR(0), 0xB4, U8G_ESC_ADR(1), 0x01, U8G_ESC_ADR(0), 0xB7, U8G_ESC_ADR(1), 0xC6, U8G_ESC_ADR(0), 0xC1, U8G_ESC_ADR(1), 0x15, U8G_ESC_ADR(0), 0xC2, U8G_ESC_ADR(1), 0xAF, U8G_ESC_ADR(0), 0xC3, U8G_ESC_ADR(1), 0x09, U8G_ESC_ADR(0), 0xC5, U8G_ESC_ADR(1), 0x22, U8G_ESC_ADR(0), 0xC6, U8G_ESC_ADR(1), 0, U8G_ESC_ADR(0), 0xE8, U8G_ESC_ADR(1), 0x40, U8G_ESC_ADR(0), 0x8A, U8G_ESC_ADR(1), 0, 0, 0, 0x29, 0x19, 0xA5, 0x33, U8G_ESC_ADR(0), 0xE0, U8G_ESC_ADR(1), 0xF0, 0x04, 0x08, 0x09, 0x08, 0x15, 0x2F, 0x42, 0x46, 0x28, 0x15, 0x16, 0x29, 0x2D, U8G_ESC_ADR(0), 0xE1, U8G_ESC_ADR(1), 0xF0, 0x04, 0x09, 0x09, 0x08, 0x15, 0x2E, 0x46, 0x46, 0x28, 0x15, 0x15, 0x29, 0x2D, U8G_ESC_ADR(0), LCD_COLUMN, U8G_ESC_ADR(1), 0x00, 0x00, 0x01, 0x3F, U8G_ESC_ADR(0), LCD_ROW, U8G_ESC_ADR(1), 0x00, 0x00, 0x01, 0xDF, U8G_ESC_ADR(0), 0x20, U8G_ESC_ADR(0), 0x53, U8G_ESC_ADR(1), 0x24, U8G_ESC_ADR(0), 0xF0, U8G_ESC_ADR(1), 0x3C, U8G_ESC_ADR(0), 0xF0, U8G_ESC_ADR(1), 0x69, U8G_ESC_DLY(100), U8G_ESC_ADR(0), 0x29, LCD_WRITE_RAM, U8G_ESC_END };

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jmz52]

@Dzenik, id 0x04 0x04 0x04 is what I am getting when display is not connected - 0x04 is "Read display identification information" register, so FSMC simply returns me last written value. Could you please check if id will change when display is not connected?

[carl1961]

will the DLION LCD code help yall? https://drive.google.com/file/d/1gIYMQCTqnYmQm7kG0WSCS2Zjvvn6pq-C/view?usp=sharing

[xC0000005]

His code seems to work when writing.

On Jan 5, 2019, at 9:55 PM, carl1961 notifications@github.com wrote:

will the DLION LCD code help yall? https://drive.google.com/file/d/1gIYMQCTqnYmQm7kG0WSCS2Zjvvn6pq-C/view?usp=sharing

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Dzenik]

@jmz52 you're right. with the display off the same code

[Dzenik]

@jmz52 in the bootloader there is a check for the display type, if the code is 0x55 one initialization otherwise the other

[jmz52]

Just FYI - STM32 core was added to PlatformIO's arduino framework. If board's "variant" is listed in .platformio\packages\framework-arduinoststm32\STM32\variants then STM32 core is used. There are no STM32F407Zx variants, so I've used closest available board to test if code will be compiled at all. There were some errors in SDIO and u8glib, but after disabling TFT and SDIO I was able to compile compile LerdgeXAndK branch using following environment settings:

[env:lerdge] platform = ststm32 framework = arduino board = disco_f407vg build_flags = ${common.build_flags} -DHAVE_HWSERIAL1 lib_deps = ${common.lib_deps} lib_ignore = Adafruit NeoPixel, c1921b4, TMCStepper, U8glib-HAL, TMC26XStepper src_filter = ${common.default_src_filter} +<src/HAL/HAL_STM32> monitor_speed = 250000

[xC0000005]

I’ve built variants and am currently building from Arduino’s IDE, but I’ll eventually switch back to PIO. Also, I want to use the same method you did to run the produced firmware through the lerdge encryption script I have (right now, I do it manually). I have SD and LCD working in a Marlin 2.0 branch. The only problems thus far are:

1. The code’s hacked up. I’ll start cleaning it soon and preparing for a PR.
2. I am not actually sure how the scaling works. I made a U8G 480x320 file and changed all the names, but either I haven’t had enough coffee or I’m just not grasping how the 24x320 actually does the scaling up. I need to essentially triple each pixel where the Robin doubles it.

You can add the lerdge variants from the poorly-named ST-3DP_Eval branch in my Arduino github, or if you want TFT/SDIO, just add the -Ds to simulate the hal_conf file.

Something still isn’t working with my UG8 library - I am manually calling the init function right now, and once I do, it all works.

On Jan 9, 2019, at 2:01 AM, jmz52 notifications@github.com wrote:

Just FYI - STM32 core was added to PlatformIO's arduino framework. If board's "variant" is listed in .platformio\packages\framework-arduinoststm32\STM32\variants then STM32 core is used. There are no STM32F407Zx variants, so I've used closest available board to test if code will be compiled at all. There were some errors in SDIO and u8glib, but after disabling TFT and SDIO I was able to compile compile LerdgeXAndK branch using following environment settings:

[env:lerdge] platform = ststm32 framework = arduino board = disco_f407vg build_flags = ${common.build_flags} -DHAVE_HWSERIAL1 lib_deps = ${common.lib_deps} lib_ignore = Adafruit NeoPixel, c1921b4, TMCStepper, U8glib-HAL, TMC26XStepper src_filter = ${common.default_src_filter} +<src/HAL/HAL_STM32> monitor_speed = 250000

— 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-452639632, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcRvJ7-aGwB8S34_3Y5qYaYcTgCJeks5vBb3ugaJpZM4YNGqo.

[jmz52]

File u8g_dev_tft_480x320_upscale_from_128x64.cpp uint16_t buffer[256]; should be uint16_t buffer[384]; for 3x scaling buffer[k++] = c; buffer[k++] = c; this double pixels horizontally, add one more buffer[k++] = c; to get them tripled for (k = 0; k < 2; k++) { double lines vertically, k < 3 to triple it and you need to add u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[256])); u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[320])); at the end of this cycle to write extended buffer 128 here is the number of bytes, so each call writes 64 pixels.

[mcheah]

My stm32 branch includes parameterized scaling based on jmz's code. https://github.com/mcheah/Marlin4MPMD/blob/lerdgex/MPMD_3dPrinter/Marlin/ultralcd_ili3941_u8glib_stm32.h

[xC0000005]

Ok, now I understand it. Once I get everything functioning without the init hacks, I’ll revisit this. I have SD and LCD working, it’s time to put this in a printer and test it. @jmz’s SDIO SD Card support has also shown me how I intend to allow Marlin to store graphics in the SPI flash. I’ll just build a block interface for the SPI flash and let the code treat the bitmaps/logos/screens like files.

On Jan 9, 2019, at 9:34 AM, mcheah notifications@github.com wrote:

My stm32 branch includes parameterized scaling based on jmz's code. https://github.com/mcheah/Marlin4MPMD/blob/lerdgex/MPMD_3dPrinter/Marlin/ultralcd_ili3941_u8glib_stm32.h https://github.com/mcheah/Marlin4MPMD/blob/lerdgex/MPMD_3dPrinter/Marlin/ultralcd_ili3941_u8glib_stm32.h — 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-452779695, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppccL7pg15qrp3Km-tmRYSLcrBoTFaks5vBigogaJpZM4YNGqo.

[mcheah]

I was curious about that. Are you going put FAT on the SPI flash? Or just hard-code block locations for the UI assets?

[xC0000005]

First I’m going to dump the FAT table that’s on the SPI flash and look at what it’s doing already. Then probably put FAT on the SPI flash.

On Jan 9, 2019, at 11:14 AM, mcheah notifications@github.com wrote:

I was curious about that. Are you going put FAT on the SPI flash? Or just hard-code block locations for 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-452804468, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcZf9DaKEx0QskrG5JLk65Y107logks5vBj-egaJpZM4YNGqo.

[xC0000005]

FYI, the SPI stuff may be using SPIFFS - it would match how they’re both using file names and offsets. In essence, they have “volumes” packed into SPI flash. The volume offsets are hardcoded. The names within the volumes determine where everything is.
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/storage/spiffs.html https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/storage/spiffs.html

On Jan 9, 2019, at 11:14 AM, mcheah notifications@github.com wrote:

I was curious about that. Are you going put FAT on the SPI flash? Or just hard-code block locations for 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-452804468, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcZf9DaKEx0QskrG5JLk65Y107logks5vBj-egaJpZM4YNGqo.

[mcheah]

Interesting. I was gonna say, full FAT seems overkill

[xC0000005]

SPIFFS doesn’t support directories, but other than that, it’s a block layout. I’m not convinced the savings make sense. Have you tried getting either the I2C flash or the NOR SPI flash working? I want to use the I2C flash as “EEPROM” and the SPI flash for UI assets.

On Jan 10, 2019, at 1:04 PM, mcheah notifications@github.com wrote:

Interesting. I was gonna say, full FAT seems overkill

— 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-453253126, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWgiPQDeBrHfZ5k_Upy_R114nItzks5vB6rfgaJpZM4YNGqo.

[mcheah]

I have not, my firmware saves settings to the SD card anyway. I'm curious why they need an I2C flash if they can just save to the internal flash. Maybe endurance concerns? Maybe it has something to do with the power loss recovery. Does Marlin support power loss recovery? Or was that an add-on prusa made for their fork?

[xC0000005]

The I2C package is specifically marketed as a wear resistant, lower energy eeprom replacement, suitable (according to marketing) for live writes. The NOR ram is slower, made for DMA transfers to the LCD. In a lot of ways, it’s the textbook (well, app note) ST design for interop with a TFT LCD.

On Jan 10, 2019, at 1:11 PM, mcheah notifications@github.com wrote:

I have not, my firmware saves settings to the SD card anyway. I'm curious why they need an I2C flash if they can just save to the internal flash. Maybe endurance concerns? Maybe it has something to do with the power loss recovery. Does Marlin support power loss recovery? Or was that an add-on prusa made for their fork?

— 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-453255209, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcf9n0JOvdAw68AEvxMXialzVBossks5vB6x2gaJpZM4YNGqo.

[mcheah]

makes sense. I can try pulling data off the I2C flash if you want to focus on the NOR one

[xC0000005]

I’m not sure there’s anything “good” there, but eventually I’d like to enable it for EEPROM usage, and also just in case Lerdge does something sneaking in whatever their next revision is and puts keys in there.

On Jan 10, 2019, at 1:14 PM, mcheah notifications@github.com wrote:

makes sense. I can try pulling data off the I2C flash if you want to focus on the NOR one

— 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-453256138, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcfzKah0BgJb-mTVg_GqAd_xaD5MJks5vB60sgaJpZM4YNGqo.

[mcheah]

I was able to initialize the I2C driver and read the contents of the serial FRAM. I've attached the dump. It uses standard EEPROM command format <I2CAddr+RWbit> . I used the HAL_I2C_Mem_Read/HAL_I2C_Mem_Write functions, library like extEEPROM should work fine. See Here for the test code

I2C address is 0xA0 (including R/W LSB)

EEPROM_dump.txt

[xC0000005]

Looking at the code disassembly and the output, I’d guess the only thing they’re storing there is some kind of print recovery and a few settings. Enabling EEPROM should be a simple as defining the I2C_EEPROM support. Wow.

On Jan 10, 2019, at 3:17 PM, mcheah notifications@github.com wrote:

I was able to initialize the I2C driver and read the contents of the serial FRAM. I've attached the dump. It uses standard EEPROM command format <I2CAddr+RWbit> A15:8 A7:0 D7:0. I used the HAL_I2C_Mem_Read/HAL_I2C_Mem_Write functions, library like extEEPROM https://github.com/JChristensen/extEEPROM should work fine. See Here https://github.com/mcheah/Marlin4MPMD/blob/a91d9335cccc31ad34d41dad656350a9c26c7434/MPMD_3dPrinter/Marlin/Marlin_main.cpp#L885 for the test code

I2C address is 0xA0 (including R/W LSB)

EEPROM_dump.txt https://github.com/LoialOtter/Open-Lerdge-X/files/2747374/EEPROM_dump.txt — 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-453296094, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWi9Uu8z6o7KA9i6R3jGZig0hQL8ks5vB8oBgaJpZM4YNGqo.

[xC0000005]

Simply adding The I2C EEPROM flag to the lerdge pins and enabling EEPROM in the configuration has made it work for both X and K.

On Jan 10, 2019, at 3:17 PM, mcheah notifications@github.com wrote:

I was able to initialize the I2C driver and read the contents of the serial FRAM. I've attached the dump. It uses standard EEPROM command format <I2CAddr+RWbit> A15:8 A7:0 D7:0. I used the HAL_I2C_Mem_Read/HAL_I2C_Mem_Write functions, library like extEEPROM https://github.com/JChristensen/extEEPROM should work fine. See Here https://github.com/mcheah/Marlin4MPMD/blob/a91d9335cccc31ad34d41dad656350a9c26c7434/MPMD_3dPrinter/Marlin/Marlin_main.cpp#L885 for the test code

I2C address is 0xA0 (including R/W LSB)

EEPROM_dump.txt https://github.com/LoialOtter/Open-Lerdge-X/files/2747374/EEPROM_dump.txt — 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-453296094, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWi9Uu8z6o7KA9i6R3jGZig0hQL8ks5vB8oBgaJpZM4YNGqo.