Looking to collaborate, have some questions #1
Comments
|
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. |
|
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? |
|
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. |
|
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? 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. |
|
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. |
|
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 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. |
|
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 |
|
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. |
|
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. |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcWpelhPGytuan8eLVQ6LEVHhhVRLks5u19RpgaJpZM4YNGqo>.
|
|
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. |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aeppcf2Op_x0lZtyPWeaB06m-1_vTlgxks5u1_ZNgaJpZM4YNGqo>.
|
|
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. |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcX_44O13qnB3jA8W7xLdguYcVxAzks5u2IeugaJpZM4YNGqo>.
|
|
decrytpedbootloader.bin.zip |
|
After checking again, the decrypted bootloader definitely starts at 0x10000, so there's something earlier, I just don't know what. |
|
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. |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppccNis36ZSdUJHxhh3wytL-sQIyAaks5u2dTSgaJpZM4YNGqo>.
|
|
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. |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aeppcf1gKIO_hVT-d8dDQHR7CMWzSB5wks5u2dorgaJpZM4YNGqo>.
|
|
Easiest would be to just disable interrupts, no? |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcaNSYFog2fSIRRiYuvbJCIPgAxuaks5u2dvegaJpZM4YNGqo>.
|
|
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? |
|
Some updates (this isn't what I was looking for, but the things you find when you go looking...): I also attached a list of the pins that are configured for FMSC (that's the alternate function 0xC). |
|
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. |
|
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? |
|
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. also Dlion Marlin GitHub of a older version may be useless |
|
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. |
|
Interesting. I was gonna say, full FAT seems overkill |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcWgiPQDeBrHfZ5k_Upy_R114nItzks5vB6rfgaJpZM4YNGqo>.
|
|
I have not, |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aeppcf9n0JOvdAw68AEvxMXialzVBossks5vB6x2gaJpZM4YNGqo>.
|
|
makes sense. I can try pulling data off the I2C flash if you want to focus on the NOR one |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcfzKah0BgJb-mTVg_GqAd_xaD5MJks5vB60sgaJpZM4YNGqo>.
|
|
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 should work fine. See Here for the test code I2C address is 0xA0 (including R/W LSB) |
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcWi9Uu8z6o7KA9i6R3jGZig0hQL8ks5vB8oBgaJpZM4YNGqo>.
|
|
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 ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcWi9Uu8z6o7KA9i6R3jGZig0hQL8ks5vB8oBgaJpZM4YNGqo>.
|
|
@xC0000005 I've reworked TFT and touch code in https://github.com/jmz52/Marlin/tree/MKS-Robin-Touch-POC These IO functions are used directly by "dev" to overcome limitations of u8g and to get significant performance boost. From you point of view what is the preferable design for 'com' function - keep IO structure to overcome u8g limitation or recreate 'com' function from scratch and use completely new data, methods, parameters and data formats? Update: Also touch screen calibration was reworked to support MKS Robin TFT v1.1 |
|
My opinion, worth exactly what you paid for it, is that the below works perfectly well. The question I have is, UG8 seems to do some pin manipulation as well, and I’m curious if we can abstract away SPI versus FSMC. I have an MKS ROBIN now (thanks to an aliexpress christmas sale, and I’ll try getting it running using the HALSTM32.
My code currently does not use DMA for SDIO, and the LCD code works, but doesn’t initialize right, which is why there’s no PR for it. Eventually I’m hoping that ST’s arduino core will catch up, because it supports pretty much every version of ST’s processors, but for now, I think you’re doing the right thing by getting it working using STM32DUINO’s support.
You can see my very much work in progress code here:
https://github.com/xC0000005/Marlin/tree/LerdgeXAndK <https://github.com/xC0000005/Marlin/tree/LerdgeXAndK>
It’s derived from the BSP layer, but fixes a few bugs with read block. I’m hooking the Lerdge-X to a printer this weekend. Once I get a few test prints running, I’ll do a PR for pins first, followed by getting an SDIO PR for the HALSTM32, and then LCD/Touch.
… On Jan 11, 2019, at 2:03 AM, jmz52 ***@***.***> wrote:
@xC0000005 <https://github.com/xC0000005> I've reworked TFT and touch code in https://github.com/jmz52/Marlin/tree/MKS-Robin-Touch-POC <https://github.com/jmz52/Marlin/tree/MKS-Robin-Touch-POC>
During initialization "com" function exposes IO function to "dev" function via
struct LCD_IO {
uint32_t id;
void (*writeRegister)(uint16_t reg);
uint16_t (*readData)(void);
void (*writeData)(uint16_t data);
void (*writeMultiple)(uint16_t data, uint32_t count);
void (*writeSequence)(uint16_t *data, uint16_t length);
void (*setWindow)(uint16_t Xmin, uint16_t Ymin, uint16_t Xmax, uint16_t Ymax);
};
These IO functions are used directly by "dev" to overcome limitations of u8g and to get significant performance boost.
Initialization sequences were reworked to support 16-bit data required for ili9328 controller.
Because of these 16-bit data requirements there is no backward compatibility with original u8g 'com' functions calls.
From you point of view what is the preferable design for 'com' function - keep IO structure to overcome u8g limitation or recreate 'com' function from scratch and use completely new data, methods, parameters and data formats?
Example:
u8g 'com' flow: set 'register select' line; write byte; reset 'register select' line; write byte
new 'com' flow: write register; write data
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcdtVY55gT3o2DMeHauhEOba04kZcks5vCGGIgaJpZM4YNGqo>.
|
|
SPI vs. FSMC can be done with two extra calls like 'begin' and 'end' that will be empty for FSMC and set/reset CS pin for SPI. A0 a.k.a Register Select pin manipulation fits perfectly to writeRegister and writeData calls. And the 'reset' call is universal. My only concern here is 16-bits vs 8-bits data over SPI. There are few ways to deal with this problem, |
|
For ESP8266 there's goofy stuff like 9-bit SPI for 18-bit color mode too. Which begs the question, how are the different color formats being handled? Is this something that can be abstracted or does that live at another level? |
|
I would imagine there’d be a pipeline prep for specific boards, in particular if we use an SPIFFS layout and have to pack the assets anyway.
… On Jan 11, 2019, at 5:33 PM, mcheah ***@***.***> wrote:
For ESP8266 there's goofy stuff like 9-bit SPI for 18-bit color mode too. Which begs the question, how are the different color formats being handled? Is this something that can be abstracted or does that live at another level?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppceOoV89pPIEId43ICMztZHUvKS6Xks5vCTt-gaJpZM4YNGqo>.
|
|
@xC0000005, I think I've found the math behind decryptionTable.
|
|
This is most likely right. If you don’t mind me asking, how did you figure it out? I had it on my “todo” list for when I have everything working, but once I got a complete 256 byte table dumped out, it was never as important. Looking down the road to STSTM32 support for this board and building in Platformio, these functions would make it simple to do the same thing you’ve done with the mks-robin boards - have the firmware encrypted after build.
Again, thank you so much for looking at this. The documentation is every bit as important as getting any one build working. If we document the hardware and encryption, there’s no reason Marlin, Repetier, Klipper, whatever can’t run on this.
… On Jan 14, 2019, at 1:49 AM, jmz52 ***@***.***> wrote:
@xC0000005 <https://github.com/xC0000005>, I think I've found math behind decryptionTable.
Two function below provides the same results as 'encryptionTable.get()' and 'decryptionTable.get()'
def encryptByte(byte):
byte = 0xFF & ((byte << 6) | (byte >> 2))
i = 0x58 + byte
j = 0x05 + byte + (i >> 8)
byte = (0xF8 & i) | (0x07 & j)
return byte
def decryptByte(byte):
i = 0xA8 + byte
j = 0x02 + byte + (i >> 8)
byte = (0xF8 & i) | (0x07 & j)
byte = 0xFF & ((byte >> 6) | (byte << 2))
return byte
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcRKCccMrwVWBO7AGmgX-lcJlVMaEks5vDFKxgaJpZM4YNGqo>.
|
|
I've looked for patterns in binary numbers format of decryptionTable, to find what bits of value are flipped by each bit of key (first guess was that there is a set of XOR operations on 0xAA byte). This gave me a set of 8 rules that successfully decoded decent chunk of decryptionTable. Then I've tried to create finer rules to cover remaining values and found that XOR is not the right tool to use (rules became more complex than patterns visible in HEX view). Then I've reverted these rules to create encryption function with another 8 rules and reworked code to make it as short as possible. Never expected to end with just 4 lines though. |
|
I don't know if @mcheah already found this but I'd bet so: The PDF has the step and dir pins for the extruder on the lerdge x reversed, as I found out today while attempting a test print. (On the other hand, hooray for finally getting to the point of a test print). |
|
You know, I noticed that at one point, but I assumed I had fat-fingered it into the header file. Good to know I'm not crazy |
|
@LoialOtter, I have a working extruder with these pins: |
|
Help guys figure it out. I tried all the ones. Simple blink code does not work. |
|
I took the settings from the board @xC0000005 and it worked! |
|
PlatformIO has updated platforms\ststm32 and packages\framework-arduinoststm32. With a little 'extra_script' magic I was able to compile Marlin using custom 'board' and 'variant' definitions
PlatformIO uses 'board' definition from
And 'variant'-specific code from The black_stm32f407vet6.py script
Tested on my nice little (100x81mm) shield for black stm32f407ve |
|
I think I've nailed down the SDIO stability problem. A patched version for HAL_STM32F1 - jmz52/Marlin@e1a29e3#diff-c12a0ff587f1645efeb7f05563654fbf |
|
Marlin now supports SDIO on STM32F4 boards (HAL_STM32) |
|
TFT screen and touch panel support for HAL STM32. |
|
The Chitu board is also a 103Z (I see you added support for it). I’ll have to see how to get the chitu environment to build using the STM32 HAL, since I’m not sure it is. Then, I know the pins/address for the Chitu stuff.
Is Bank4 the right setting for the FSMC? I would think this would change based on the address selection.
… On May 27, 2020, at 2:32 AM, Alexander Gavrilenko ***@***.***> wrote:
TFT screen and touch panel support for HAL STM32.
Currently for 320x240 screens but can be extended to 480x320 with appropriate MarlinUI implementation.
Also some extra coding is needed for appropriate FSMC and SPI initialization on STM32F4
MarlinFirmware/Marlin#18130 <MarlinFirmware/Marlin#18130>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4M2WYNZYB3OHMMF4ALRTTM2NANCNFSM4GBUNKUA>.
|
|
@xC0000005 you are right, bank parameter depends on chip select pin. |
|
We're getting closer... |
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.
The text was updated successfully, but these errors were encountered: