[FR] tronxy x5sa

[ftoz1]

Hi, after several days of conversation to tronxy, they send me schematics pin maps for smt32f103zet6 board. It should help community to port marlin on many tronxy printers. x5sa-main_board-2.pdf

[InsanityAutomation]

I believe this matches the Chithu controller, as it is one of their boards. The time to reverse engineer the touchscreen has been my only holdup getting into this....

[ftoz1]

Its not exactly same board as chitu f mini, but some versions of x5sa has it. It has different stepper driver, but maybe should be close.

[ftoz1]

From what I check, pins match with pins_chitu3d.h but not sure about LCD and touch.

[pinchies]

Interesting, but not unexpected - the pinout for SD and LCD is nearly identical as JGAurora A5S/A1. Only some differences in LCD backlight and chip enable/chip select pins. Wondering if the same JGAurora bootloader might work too?

[ftoz1]

I cant find aurora scheme, i compare it with robin board, lcd has same connection as robin, sd little different, but i notice that many other boards had 6 pin header for programing, my board not and scheme not show signals on it. So havnt sure how to connect to be right.

(EDIT: Removed mail formatting)

[pinchies]

JGAurora A5S reverse engineered pinout is here. Some errata with the unused endstop pins I haven't corrected yet, but otherwise should be mostly right.

You might want to read up on SWD, it's dead easy. You've got the zet6 chip datasheet, and the full schematic in your post above ... all the answers are there about where you need to connect the ST-link.

[ftoz1]

aurora code work with atmlh eeprom? Tronxy has similar one too, but i am not sure which data it store.

(EDIT: Removed mail formatting)

[Keltere]

So the lcd of the tronxy can now be used with any other motherboard? I wanted to use it with the skr pro 1.1

[ftoz1]

Probably not, must check schematics for LCD buc connections and the board. If wires and connector same, then y can try it. If not match can damage LCD or board. Seems china LCD has no standart for that and its better to buy printer board with LCD if plan to run it.

(EDIT: Removed mail formatting)

[xC0000005]

@ftoz1 or @InsanityAutomation, have either of you successfully initialized the Tronxy/Chitu board's LCD? I have a known working init sequence, but I suspect my FSMC configuration isn't right.

[InsanityAutomation]

I havnt physically messed with the board, I have a machine sitting untouched on a shelf. I have been following @ftoz1 's progress which seems to have stopped over the holidays. It was up and working and I wouldnt mind getting into it at some point to help wrap it up when other projects get closed up.

[ftoz1]

Answer isnt so easy. To start is check u8g_dev_tft_320x240_upscale_from_128x 64.cpp. there are all LCD init sequences. But there is LCD id read from 04h register and when LCD id is unknown, it not run init, y still see blank screen. in marlin 2.0.0 is on 460 line. Also is good add lines:  

SERIAL_ECHOPAIR("LCD manufacturer ID: 0x", (lcd_id & 0xF000)>>12);
  SERIAL_ECHO((lcd_id & 0x0F00)>>8);

  SERIAL_ECHO((lcd_id & 0x00F0)>>4);
  SERIAL_ECHOLN(lcd_id & 0x000F); 

It prints your lcd id into serial console and then y can add to if.

I am do my own, because marlin use ug8_lib, which is primary monochome lcd library. So i delete all files in lcd and rebuild all gui.

[xC0000005]

I decompiled Chitu’s bootloader (it’s how I reverse engineered their encryption scheme), so I know every LCD it supports (there’s four or five, I don’t recall right off hand). How are you configuring FSMC and SRAM?

[ftoz1]

Sorry, i am confused by community. I do my own. I dont agree with marlin structure. For me its too mess now. I deleted all files from lcd dir to work clean gui. I have it finished it now, but still lot of work. connect to functions. Its hard undestant some things and some ppl imagine that edit few lines and all will be work. Simply i am tired by discord and talk about. If people read code instead of forum, they should understand, what is hell work.

[ftoz1]

First i do nothing with bootloader. Y can use original, but need find adress on stock FW, So need dump stock FW edit in hex and find gap between bootloader and FW. At me is 0x08008800, but tronsy x5sa is not exactly chitu bord, look like clone of it. There need to put marlin to check by some serial monitor to boot right. if boot right, y must find first your lcd id and mod that upcale file to boot original marlin. if your LCD will work, can mod next. My ldscrips are same as chitu ram (rwx) : ORIGIN = 0x20000000, LENGTH = 64K - 40   rom (rx)  : ORIGIN = 0x08008800, LENGTH = 512K - 34K, py scrip i use from jgaurora

}

[InsanityAutomation]

It is unfortunate that some of the language barrier differences as well as some points on both sides where people were too touchy caused some issues on Discord. Its unfortunate. We all agree that code is old and has had a ton stacked on and is in need of a rewrite. It will move up the list as the 32 bit space stabilizes im sure but for now its working so things that aren't are getting attention.

That said I for one feel good progress was being made and would hate to see it lost, and would like to see it make its way in any functional form into the code base here. A good writeup of the process would be used my many im sure, even in the state is was in last time I saw it!

[xC0000005]

Agreed. FTOz, I’ve already done exactly this process (If you build using the chit_f103 environment, you’ll see your linker script and mine are near identical, and the resulting update.cbd file is encrypted for disk update.) I’m not asking for you to explain everything,

I simply want to know how you’re configuring FSMC and SRAM.

Trust me, I’ve already got code running on the Tronxy and Chitu boards, either at 0x8000000 or using the proprietary bootloader. And yes, at 115200 baud, at boot, the LCD_ID function in the built in bootloader will dump the id (it also does it in the GCODE handler and a couple other places).

If you have code of any sort, I’d be happy to read it instead of asking questions, since thus far, I’ve simply read the assembly in binaryninja to work out how things operate on that board.

On Feb 5, 2020, at 11:05 AM, InsanityAutomation notifications@github.com wrote:

It is unfortunate that some of the language barrier differences as well as some points on both sides where people were too touchy caused some issues on Discord. Its unfortunate. We all agree that code is old and has had a ton stacked on and is in need of a rewrite. It will move up the list as the 32 bit space stabilizes im sure but for now its working so things that aren't are getting attention.

That said I for one feel good progress was being made and would hate to see it lost, and would like to see it make its way in any functional form into the code base here. A good writeup of the process would be used my many im sure, even in the state is was in last time I saw it!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14655?email_source=notifications&email_token=AHVGS4LJ3UPMMVUXHADHQILRBMEZLA5CNFSM4IEPCY42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK4TBFQ#issuecomment-582561942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4K55LLRSXCJXKWE4MTRBMEZLANCNFSM4IEPCY4Q.

[tpruvot]

there are now 3 types of FSMC devices handled... st7789v ili9328 and ili9341 (all are native 320x240)

the remaining common ones have a bigger resolutions (480x320), so imo they need a specific cpp unit to handle them properly...

[xC0000005]

Right - that’s why I extracted the init sequences used by the bootloader, those used by the tronxy and chitu firmware (Chitu says Tronxy customized their firmware), and compared to the manufacturer’s recommendations. Then I’ll dump the sequence into a handler similar to the others. My current one is 9844, but adding the others shouldn’t be much more work.

On Feb 5, 2020, at 11:29 AM, Tanguy Pruvot notifications@github.com wrote:

there are now 3 types of FSMC devices handled... st7789v ili9328 and ili9341 (all are native 320x240)

the remaining common ones have a bigger resolutions (480x320), so imo they need a specific cpp unit to handle them properly...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14655?email_source=notifications&email_token=AHVGS4PC6IHF3UQJ4YPMADTRBMHQXA5CNFSM4IEPCY42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK4VPSY#issuecomment-582571979, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4P445SO775QC5PO7ZDRBMHQXANCNFSM4IEPCY4Q.

[ftoz1]

Its true i not touch it ftom holiday, but its not lost. I dont want get out it now, when its not state point version. Its now gui without function connect, so press move do nothing and i dont want to people punish me that dont work. When i connect to functions, i can reveal some code, but sometimes i doubt if has sence. Still many problems on current marlin. I interestest now in RTOS marlin console to port it and start some clean.

[tpruvot]

yep, ili9488 is the big new from mks, sold with the robin2 (480x320)

[ftoz1]

its good touch this, clean hw structure, no dual system. But i am also little tired by this, people have plenty board and still buy some new. Dont know, what they find. This board maybe run FSMC by 2x, but if add asm routines to old board, it speed up 10x.

[ftoz1]

Y dont need change nothing from FSMC, that only set mcu gpios as output. Most important are that function there LCD_IO_WriteData, LCD_IO_WriteReg and Multiply also. that is base of all. Those LCD works as copy memory to memory. By writing values y choose lcd register and write data y send data by bus into reg. There is nothing like framebuffer. It simply copy byte per byte from memory into lcd matrix.

[rhapsodyv]

BOARD_CHITU3D doesn't work with X5SA?

[ftoz1]

Dont know, i use some some files from jgsaurora and own pin file according original schematics

[rhapsodyv]

@ftoz1 https://github.com/MrPoke21/Marlin-Chitu-board-support

[ftoz1]

Whats work on this? Work properly sd card and serial console? Original git is too much buggy and need a lot of tweaking to get solid firmware.

[avion23]

@ftoz1 https://github.com/MrPoke21/Marlin-Chitu-board-support

Did you try that? With my Tronxy X5SA the device stays dead after flashing.

I reenabled the script for the bootloader encryption. And I changed the print statements to print(...) to satisfy python3.

I can always go back to the stock firmware https://www.thingiverse.com/asset:248437 from this thread https://www.thingiverse.com/groups/tronxy/forums/general/topic:33023 Nelson at https://hackaday.io/project/167594-chitu-3d-printer-mainboard-hacking# is working on an improved encryption script for the bootloader.

[ftoz1]

Did you try that? With my Tronxy X5SA the device stays dead after flashing.

No, it look like fork of original github and look nothing usefull. Also original github is quite useless for that if not want spent years with twaeking. For chitu board is there https://github.com/xC0000005/Marlin/tree/ LerdgeXAndK. trupvot has alphawise git, and pinchies jgsaurora git. its similar hw and y can try routines from that.

[xC0000005]

I have built the code linked below - it runs just fine as long as you flash it without a bootloader (it does not run with the Chitu bootloader). We should be able to use this as a pins definition for @jmz’s FSMC lcd code as well.

[rhapsodyv]

The PINS is almost exactly the same of my board, but not all. I think we need more board definitions. One Chitu Board seems doesn't fit all.

[ftoz1]

Schematics is base of that project. Without that ist pain and random work. I also stuck in one point, where was mistake in schematics and thats hard diagnose, beacause of thousand possibilities. Most ppl want fully working marlin FW just now, but they dont know, which LCD type they have, which bus it use and where to set.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.