search

LoialOtter / Open-Lerdge-X

Open firmware for the Lerdge-X V1.0.4 (possibly others)
MIT License
5 stars 1 forks source link

Looking to collaborate, have some questions #1

Open mcheah opened 6 years ago

mcheah commented 6 years ago

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.

xC0000005 commented 5 years ago

@mcheah , the ESP module is a pretty much vanilla ESP-01S.

mcheah commented 5 years ago

Right... But what pins does it connect to on the stm32?

xC0000005 commented 5 years ago

I’ll see what the firmware does and get back to you.

On Dec 13, 2018, at 7:08 PM, mcheah notifications@github.com wrote:

Right... But what pins does it connect to on the stm32?

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

Dzenik commented 5 years ago

Hi guys! Made a gpio scheme connection of Lerdge-K. Maybe help you. Lerdge-K.pdf

carl1961 commented 5 years ago

@Dzenik , thanks! how was you able to do this? with a volt meter? EDIT: just realized Open-Lerdge-X-master is Lerdge K pin-out

Dzenik commented 5 years ago

Lerdge-K.pdf Added measurement schemes for heatbed and hotend sensors.

xC0000005 commented 5 years ago

Anyone know what the W Endstop is? X, Y, Z I get. W, I don't.

mcheah commented 5 years ago

I think W is typically Z-min for delta printers

xC0000005 commented 5 years ago

Ok. I’lm leaving it out of the pins definition (note, if anyone has already build the pins.h file, you won’t hurt my feelings).

On Dec 16, 2018, at 7:50 PM, mcheah notifications@github.com wrote:

I think W is typically Z-min for delta printers

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

xC0000005 commented 5 years ago

I pushed a preliminary pins and board definition for Lerdge X and K. Please note that these are VERY preliminary, and there's good reason for it:

  1. The LCD pins are addressed using FSMC. I'm not 100% sure these pins will have any meaning. The good news is that Mks-Robin needs FSMC support, too.
  2. SPI - The flash ram's sitting at the other end of this, and it's not going to be used for that. Plus, Marlin's SPI config is going to need some beefing up to support this unless I'm missing something obvious.
  3. SD - Again, it's on the other end of SDIO and the pins aren't negotiable, not relevant to a pins implementation. In fact, FatFS as NOT in marlin supports a SDIO implementation, but I don't think that one's in Marlin yet. (Also, MKS-Robin also needs SDIO.)
mcheah commented 5 years ago

When you're talking about MKS-robin, you're talking about development on the Marlin 2.0 branch? Or is there a separate repo for the Robin?

xC0000005 commented 5 years ago

There’s an open PR for Mks-Robin in 2.0.

On Dec 16, 2018, at 8:16 PM, mcheah notifications@github.com wrote:

When you're talking about MKS-robin, you're talking about development on the Marlin 2.0 branch? Or is there a separate repo for the Robin?

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

mcheah commented 5 years ago

the MKS-Robin PR looks pretty barebones. I wouldn't hold my breath on ST providing FSMC or SDIO hardware support to their arduino port. Also, having worked to bring in hardware SD support to the F070 for the MPMD, I can tell you that it's going to be pretty tough to integrate it into the Arduino SDFat library. All their drivers and examples are pretty much set up to hook into FatFS. That's not to say that it can't be done or that you couldn't pull in FatFS into Marlin, moreso that I foresee this being a pain point. But there's nothing to stop you from implementing SD as a SPI device as is typically done, it just significantly drags down the performance. What about USB-MSC? Is this something that could even be supported by Marlin? I know that I plan on using the USB port as a virtual comm port, but in theory you could retain the USB host support and use a FTDI-like bridge on the exposed UART.

xC0000005 commented 5 years ago

The same owner of the core wrote the STM32SDIO Arduino library, so I’m hoping. The way this would work is relatively simply - you can see that FATFS in Marlin has a chip command layer, and we abstract SDIO vs SPI there…IF I can get it working.

On Dec 16, 2018, at 8:35 PM, mcheah notifications@github.com wrote:

the MKS-Robin PR https://github.com/MarlinFirmware/Marlin/pull/12650/commits looks pretty barebones. I wouldn't hold my breath on ST providing FSMC or SDIO hardware support to their arduino port. Also, having worked to bring in hardware SD support to the F070 for the MPMD, I can tell you that it's going to be pretty tough to integrate it into the Arduino SDFat library https://github.com/greiman/SdFat. All their drivers and examples are pretty much set up to hook into FatFS. That's not to say that it can't be done or that you couldn't pull in FatFS into Marlin, moreso that I foresee this being a pain point. But there's nothing to stop you from implementing SD as a SPI device as is typically done, it just significantly drags down the performance. What about USB-MSC? Is this something that could even be supported by Marlin? I know that I plan on using the USB port as a virtual comm port, but in theory you could retain the USB host support and use a FTDI-like bridge on the exposed UART.

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

LoialOtter commented 5 years ago

The micropython code also has SDIO support but I do believe it's bitbanged. Not sure if that'll be helpful or not.

Dzenik commented 5 years ago

Did you watch this library? https://github.com/stm32duino/STM32SD

xC0000005 commented 5 years ago

That’s the one I’ve been trying to use. Today I accidentally short circuited my USB adapter for the lerdge. One resistor near the edge of the board let out its smoke. The CH340 still functions, so no telling what is broken, but I went ahead and made the ugliest diagram on earth for how the expansion header works. I’m still thinking this is a pretty much stock ESP8266-1 module. My attempts to write to the serial are not working, despite my timers being fairly accurate.

On Dec 17, 2018, at 1:48 AM, Dzenik notifications@github.com wrote:

Did you watch this library? https://github.com/stm32duino/STM32SD https://github.com/stm32duino/STM32SD — 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-447783202, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcSSZF945IaVvoNml-RNhrtC2iVSwks5u52hmgaJpZM4YNGqo.

Dzenik commented 5 years ago

Did you write the firmware from arduino?

xC0000005 commented 5 years ago

Yes.

On Dec 17, 2018, at 10:00 AM, Dzenik notifications@github.com wrote:

Did you write the firmware from arduino?

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

Dzenik commented 5 years ago

TestUART.zip Can you test this code? Encrypt and what are you doing there) PA9 - TX Baudrate -115200

xC0000005 commented 5 years ago

I'm waiting on some hardware to arrive to replace my USB->TTL converter to continue serial work. One update for the X. PC7 is the green status LED in the corner of the board/on the LCD PCB, PC6 is the dim yellow LCD near the bed connnection.

xC0000005 commented 5 years ago

I added the bootloader dumped from a -K board thanks to @carl1961 to my hackaday. If you have a wiped K board, you can try updating it and see if it works. I have every reason to think so, since I can see my arduino sketch sitting in ROM at the place where I figured the bootloader ended. Enjoy.

Dzenik commented 5 years ago

I'm waiting on some hardware to arrive to replace my USB->TTL converter to continue serial work. One update for the X. PC7 is the green status LED in the corner of the board/on the LCD PCB, PC6 is the dim yellow LCD near the bed connnection.

Is it on the Lerdge-X board?

xC0000005 commented 5 years ago

Yes. There’s three total LEDs. Dim yellow in the middle “bottom” near the hotend/bed connections, bright green in the upper “right” of the board (this is what flashes when the bootloader is updating firmware) and the LED on the display board, which is chained to the bright green one.

On Dec 19, 2018, at 12:06 PM, Dzenik notifications@github.com wrote:

I'm waiting on some hardware to arrive to replace my USB->TTL converter to continue serial work. One update for the X. PC7 is the green status LED in the corner of the board/on the LCD PCB, PC6 is the dim yellow LCD near the bed connnection.

Is it on the Lerdge-X board?

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

xC0000005 commented 5 years ago

FYI, I got Serial1 sending tonight by altering the pinMap to make sure the serial pins got their alternate functions set correction. Receive doesn't work yet for some reason, and since I was testing it by sending a G28 to Marlin, I'm not sure what the reason is. Also, I have to keep the baud rate low right now - I'm working on understanding why. I'd bet money the ESP connector on the expansion board is going to turn out to be the "standard" one and when Lerdge says a regular module won't work, what they mean is "We don't want it to work." I'll figure out what's keeping RX from working eventually, but there's a number of possibilities:

  1. bad code (in particular, the pinmap being wrong - this is the variant's pin map).
  2. The RX pin not being where we'd expect it to be.
  3. Marlin going away but still firing the heartbeat indicator since that runs in the ISR.

We'll see.

mcheah commented 5 years ago

@xC0000005 , Trying to load arbitrary code with the stock bootloader, not getting any success. To be clear, the application is loaded onto to flash at 0x08060000, but the vector table is loaded at 0x0801000? I have some confusion regarding this because the stock firmware is 332k, and 0x08060000 as a start location would not fit the entire binary. So either it gets split or there's some tomfoolery regarding the vector table. I've tried setting up my linker script at both locations and I can't seem to get anything to run. Can you post your blinky code/binary somewhere so I can compare against what I'm doing?

xC0000005 commented 5 years ago

Ok, catching everyone else up on what I told @mchea over Facebook. When you’re reverse engineering an ARM firmware, a lot of guessing about the vector table’s address is based on where jumps suddenly start producing valid code that actually does something. 0x60000 was one place where it did, but I was wrong. I’m sure it’s the 0x10000 one. You can check out the variant in my STM32duino branch and see how I have it set up.

Also, remember the LD script and the VTOR are two halves of the same coin. Your LD script should assemble the binary in a way that makes your vector table offset make sense.

On Dec 26, 2018, at 8:46 AM, Dzenik notifications@github.com wrote:

try set begining application at 0x08020000

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

xC0000005 commented 5 years ago

I copied the Clock Init code (mostly) from MicroPython and was able to successfully initialize USB using the Arduino Core. I discovered something unpleasant about the ESP8266 board - when you plug in USB, it disables POWER to the ESP8266. I'm not sure if this happens on the expansion board or the motherboard, but Marlin supports two serial ports in 2.x and it would be nice to enable both. I haven't tried SDIO yet with the proper clock config - that'll be soon, even though Marlin doesn't properly support it.

carl1961 commented 5 years ago

xC0000005 , that also happens on a lerdge 3d printer, if you plug the computer to your printer it disconnects the WiFi.

xC0000005 commented 5 years ago

FYI - with proper clock initialization, the STM32SDIO library is perfectly happy to read/write the SD card. Marlin of course doesn't use this library or allow you to interface with it, but that's another layer to unravel. FSMC investigation may come sooner than I planned.

Dzenik commented 5 years ago

@xC0000005 , Trying to load arbitrary code with the stock bootloader, not getting any success. To be clear, the application is loaded onto to flash at 0x08060000, but the vector table is loaded at 0x0801000? I have some confusion regarding this because the stock firmware is 332k, and 0x08060000 as a start location would not fit the entire binary. So either it gets split or there's some tomfoolery regarding the vector table. I've tried setting up my linker script at both locations and I can't seem to get anything to run. Can you post your blinky code/binary somewhere so I can compare against what I'm doing?

ld script changes / Highest address of the user mode stack / _estack = 0x20010000; / end of RAM /

/ Specify the memory areas / MEMORY { FLASH (rx) : ORIGIN = 0x8010000, LENGTH = 312K

Dzenik commented 5 years ago

Happy New Year!

xC0000005 commented 5 years ago

Happy New Year to you as well!

Aand in case I didn’t answer your question from earlier in the thread, you want your LD script and your VectablOffset to both use 0x10000. You can pick up working ld scripts and vector table offset definitions from my ST arduino core github branches.

On Dec 31, 2018, at 8:39 AM, Dzenik notifications@github.com wrote:

Happy New Year!

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

Dzenik commented 5 years ago

Yes, I changed the ld script and VECT_TAB and the program did not start. Not yet changed _estack and MEMORY order array

xC0000005 commented 5 years ago

Are you running with Lerdge’s bootloader?

On Dec 31, 2018, at 8:57 AM, Dzenik notifications@github.com wrote:

Yes, I changed the ld script and VECT_TAB and the program did not start. Not yet changed _estack and MEMORY order array

— 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-450668497, or mute the thread https://github.com/notifications/unsubscribe-auth/Aeppcax9oJb5RlYcrP2ecz4EL_KFKxY-ks5u-kH6gaJpZM4YNGqo.

Dzenik commented 5 years ago

Yes

xC0000005 commented 5 years ago

Does the lerdgecrypt.py script successfully encrypt the binary?

On Dec 31, 2018, at 9:00 AM, Dzenik notifications@github.com wrote:

Yes

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

Dzenik commented 5 years ago

Yes

xC0000005 commented 5 years ago

Ok. Build a blink binary (blink both LEDs. :)) and send me both the unencrypted one for me to look at in binary ninja and the encrypted one for me to load on my board. We’ll make sure your toolchain works and then you can get fancy.

On Dec 31, 2018, at 9:01 AM, Dzenik notifications@github.com wrote:

Yes

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

Dzenik commented 5 years ago

Debug.zip

xC0000005 commented 5 years ago

Ok, Binary Ninja says it’s a fairly normal blink. Testing on the lerdge K board will have to wait until this evening, as it’s time for me to head to work. I do almost everything right now on the Lerdge-X. Other than dumping the bootloader from the K, I haven’t tinkered with it while I work out the gritty details of Marlin, SDIO, and the LCD, so it’s entirely possible there’s something different about the K.

Which pins are you pulsing for the LED?

On Dec 31, 2018, at 9:04 AM, Dzenik notifications@github.com wrote:

Debug.zip https://github.com/LoialOtter/Open-Lerdge-X/files/2718670/Debug.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-450669276, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcdOTxWu0OER1LhZGkv-kDidJko3jks5u-kOpgaJpZM4YNGqo.

Dzenik commented 5 years ago

PB6 Led marked on board Lerdge-K

xC0000005 commented 5 years ago

That looks right. I’ll test when I’m home and see if I can figure out what’s going on.

On Dec 31, 2018, at 9:14 AM, Dzenik notifications@github.com wrote:

PB6 Led marked on board Lerdge-K

— 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-450670315, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcXHxppobuVw7sA6UHdLQxyCe--1Jks5u-kXugaJpZM4YNGqo.

mcheah commented 5 years ago

FYI, I had to change the .ld script and use @xc0000005's startup.s code to get things to boot. I also discovered that changing the MODER register would lock things up for some reason, haven't really investigated further.

@dzenik, are you using the stm32 arduino toolchain or the stm32 hal directly?

xC0000005 commented 5 years ago

What startup code? I dropped the custom.s a while back. It’s literally using the HAL startup. I would guess whatever you were using doesn’t load the SP, which the bootloader does not.

On Dec 31, 2018, at 9:18 AM, mcheah notifications@github.com wrote:

FYI, I had to change the .ld script and use @xC0000005 https://github.com/xC0000005's startup.s code to get things to boot. I also discovered that changing the MODER register would lock things up for some reason, haven't really investigated further.

@Dzenik https://github.com/Dzenik, are you using the stm32 arduino toolchain or the stm32 hal directly?

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

Dzenik commented 5 years ago

FYI, I had to change the .ld script and use @xC0000005's startup.s code to get things to boot. I also discovered that changing the MODER register would lock things up for some reason, haven't really investigated further.

@Dzenik, are you using the stm32 arduino toolchain or the stm32 hal directly?

HAL from STM32 Workbench

Dzenik commented 5 years ago

We can use @jmz52 code for LCD. Need proper config FSMC and use initialize code for our display.

jmz52 commented 5 years ago

@xC0000005, I've added support for SDIO for Robin board. Just need a day or two for minor cleanup before sending PR. Hardware initialization is handled by stm32duino, but rest of the code should be more or less reusable for F4 with different framework.

xC0000005 commented 5 years ago

How did you abstract away Marlin’s direct use of the SD card? I’m currently using ST’s arduino library for SDIO, which works, but I was just beginning to figure out how to substitute it in for Marlin’s pretty much direct SD access.

On Dec 31, 2018, at 10:59 AM, jmz52 notifications@github.com wrote:

@xC0000005 https://github.com/xC0000005, I've added support for SDIO for Robin board. Just need a day or two for minor cleanup before sending PR. Hardware initialization is handled by stm32duino, but rest of the code should be more or less reusable for F4 with different framework.

— 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-450680529, or mute the thread https://github.com/notifications/unsubscribe-auth/AeppcWr-aamdEiJV8G4pGYPRrhZUmUEVks5u-l6kgaJpZM4YNGqo.

jmz52 commented 5 years ago

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.