[FR] New Artillery not flashing LCD on GD32F305

[Help3D-Padova]

Description

There some Artillery Genius PRO or X2 that are not able to flash the LCD firmware.

Steps to reproduce

Try to flash as usual

Actual behavior

MKSTFT28.bin is not detected and the flash is not able to start

Hardware Variant

It seems that the new microcontroller is based on GD32F305 - VERIFIED

TFT Firmware Version & Main Board Firmware details

The bootloader is V3.0.4

Additional Information

https://github.com/artillery3d/genius-pro-tft-firmware this firmware can be flashed without issue

@digant73 i'm not able to reproduce this issue because i have an older lcd but i have some user that can try some beta firmware.

[Dave811]

I tired both (@ciotto , @Fourmi ) of your repos (first flashed with original to test that my SD-Card is working, and after that I used your repos to compile it), but both dont work on my end :/

[ciotto]

@Dave811 you used mkstft28evo.bin as filename?

[Dave811]

@ciotto yes I used that name, and also in all uppercase, just in case. But both dont work.

[Fourmi]

@Dave811 , yes, compile is ok ,but upload don't load with SDcard it is this point that should be seen and which blocks me to advance a little more

[ciotto]

Finally I was able to update the TFT firmware with the one compiled by @Fourmi (I have a video), but in the end, nothing worked.

The trick is to use the original firmware as a base, replacing the mkstft28evo.bin and adding other BIGTREETECH firmware files, so we have:

• mks_font/
• mks_pic/
• MksWifi.bin
• mks_config.txt
• mkstft28.bin
• mkstft28evo.bin (replaced by GD_TFT28_X2.27.x.bin)
• TFT28
• config.ini

The procedure requested me to do e touchscreen calibration, but I can't do anything. I suppose that the pin mapping is wrong.

After restarting, the screen shows the BIGTREETECH logo but nothing else.

Now I re-flashed the original firmware and all works fine.

I think that it's a great result, now we can fix the firmware.

I'll update you ASAP with more details and some images.

[digant73]

@ciotto, @Fourmi after the first successfull installation, try to simply re-install only the BTT files:

• mkstft28evo.bin
• TFT28
• config.ini

Verify if the installation is performed or not. If installation is performed as expected (you see on screen the binary, font, icons and config.ini update process) and touch screen during calibration process is not working, you must start from reviewing the following pins mapping in pin_MKS_TFT28_X2.h:

// XPT2046 Software SPI pins for touch screen
// It needs CS/SCK/MISO/MOSI for Software SPI and TPEN for pen interrupt
#define XPT2046_CS   PC9
#define XPT2046_SCK  PC10
#define XPT2046_MISO PC11
#define XPT2046_MOSI PC12
#define XPT2046_TPEN PC5

This mapping is currently matching the one used on the X1 board (based on old STM chip). Possibly in the X2 board they have been changed.

[ziirish]

@Fourmi can you provide a bit of details on how you compiled the firmware? I tried to compile it based on your repo but I'm encountering the following error:

$ pio run
Processing MKS_TFT28_X2 (board: GD32F305VC_0X3000; platform: https://github.com/CommunityGD32Cores/platform-gd32.git; framework: spl)
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Error: Unknown board ID 'GD32F305VC_0X3000'

Thanks

[ciotto]

I want to try to do some changes but after the first installation, the process never reaches the end.

The first time, the process was this:

• original firmware update
  • updating
  • SPI Flash Erasing
  • Erasing success
  • Load PIC
  • copy _bmp_*.bin files
  • Load font
  • copy 2 0:/mks_font/*.bin files
  • Complete
• BTT firmware update
  • Updating fonts
  • SD:TFT28/font/*.fon files
  • Updating Icons
  • Copy SD:TFT28/bmp/*.bmp files (with preview)
  • Updating Configuration...
  • Touch Screen Calibration

Now the update stop after Complete screen, I don't know why.

Does someone else have the same problem?

I'll do more test.

[nomc2]

Finally I was able to update the TFT firmware with the one compiled by @Fourmi (I have a video), but in the end, nothing worked.

The trick is to use the original firmware as a base, replacing the mkstft28evo.bin and adding other BIGTREETECH firmware files, so we have:

• mks_font/
• mks_pic/
• MksWifi.bin
• mks_config.txt
• mkstft28.bin
• mkstft28evo.bin (replaced by GD_TFT28_X2.27.x.bin)
• TFT28
• config.ini

The procedure requested me to do e touchscreen calibration, but I can't do anything. I suppose that the pin mapping is wrong.

After restarting, the screen shows the BIGTREETECH logo but nothing else.

Now I re-flashed the original firmware and all works fine.

I think that it's a great result, now we can fix the firmware.

I'll update you ASAP with more details and some images.

Did not work for me on my X2, I get stuck at a black screen that says complete and the TFT never reboots. Are you sure you just replaced the mkstft28evo.bin file and not something else as well?

[ciotto]

I'm pretty sure, but now I have the same problem, so probably something else is different... 😩

[ciotto]

One more update.

I tryed the procedure using the MKS_TFT28_V4.0.27.x.bin file and doesn't stop after the "Completed" screen, but this is what I see.

As usual, after I can flash the original firmware.

[ciotto]

I'm trying a new approach. Starting from the STM32 version of the firmware, I have a "working" firmware that shows the BTT logo:

Starting from this, I want to try some debugging.

If you want to try, here is available the "working" firmware with all the file and folder needed for uploading.

[FabulosoDev]

I have a "working" firmware that shows the BTT logo

Promising progress you made 👍. Could you please describe what 'working' means in that context? Is it the regular STM firmware you were able to compile for the GD32 MCU? Thanks for your reply.

[ciotto]

As I said, "working" means that it "shows the BTT logo", literally 🙂.

This version was essentially built using STM32 libraries, after flashing show the logo screen with the Card inserted and Card removed! strings (as you can see in my previous post).

After working on it for a day, now I reached the same result with a version built using the GB32 libraries.

This version has some screen glitches and is slower, I don't know why (yet). Fixed

In any case, for both versions the problem that stop the execution on boot screen is this loop on ModeSwitching.c:

while (OS_GetTimeMs() - startUpTime < BTT_BOOTSCREEN_TIME)  // display logo BTT_BOOTSCREEN_TIME ms
{
  loopProcess();
}

The loop never ends due to the fact that OS_GetTimeMs() is always 0. Probably it's related to the timer interrupt call.

[Ricky1966]

@ciotto I need to write to you but the message was returned to your site's email address. Could you write me?

[ciotto]

@Ricky1966 I fixed the issue with my email and now you can write me.

[Ricky1966]

@ciotto If you think problem nested in the interrupt OS_GetTimeMs(), have you try to replace this value with a fixed as 1000 (1 second)?

[MirakelPrints]

@Ricky1966 Sadly this is not a fixed time. Its a counter incremented on interrupt. See os_timer.c#L76

[ciotto]

Exactly, as @MirakelPrints said the counter it's incremented every millisecond on interrupt and on this depends every time-related task.

Moreover, interrupt manage many other things like, UART and I2C communication, buzzer, etc.

[MirakelPrints]

@ciotto have you tried to skip showing boot screen by commenting #define SHOW_BTT_BOOTSCREEN ? maybe there is an issue in that early stage of bootup

[Ricky1966]

Maybe this you have seen yet, but https://www.gigadevice.com/manual/gd32f307xxxx-user-manual/ Could be helping?

[Ricky1966]

This link could help? https://www.google.com/url?sa=t&source=web&rct=j&url=https://github.com/ivaniacono/GD32-RISCV-Example/blob/master/GD32VF103_Firmware_Library/GD32VF103_standard_peripheral/Include/gd32vf103_rcu.h&ved=2ahUKEwi2ycSo45z9AhXIsaQKHdmQB3cQFnoECA8QAQ&usg=AOvVaw3kHXWT9gXjdzJFNmwywWrA

[gagipro]

@ciotto have you tried to skip showing boot screen by commenting #define SHOW_BTT_BOOTSCREEN ? maybe there is an issue in that early stage of bootup

tried it and it's locked @V3.0.4 screen

[gagipro]

Yes it's strange that it does calibration first time but not other flash afterwards

[ETE-Design]

Yes it's strange that it does calibration first time but not other flash afterwards

Have you tried to add reset.txt to the sd-card??

[gagipro]

Yes it's strange that it does calibration first time but not other flash afterwards

Have you tried to add reset.txt to the sd-card??

No I Can try tomorrow but WE are probably missing some pins mappings like explained in previous posts...

Or some clock adaptations, I have no clue at all but if someone Can have a look at source code I Can also try to compile and test.

[gagipro]

didn't change anything, I reflashed original and everything's back to normal ... at least we can try as many times as we need to

[gagipro]

ok I rechecked everything and it seems I am not able to recompile properly like the binary firmware from @Fourmi I must miss something Fourmi's binary is copying properly all bmps but if I recompile one myself it doesn't do the same.

[Ricky1966]

@gagipro If you explicate me all passage to recompile I also could try to help you. Say me what I must search (and where) and I look to help all community to find "The Force"! 🤣 Maybe with GD32F305 Datasheet and STM32, comparing, could be jumping out which are the differences

[gagipro]

@gagipro If you explicate me all passage to recompile I also could try to help you. Say me what I must search (and where) and I look to help all community to find "The Force"! 🤣 Maybe with GD32F305 Datasheet and STM32, comparing, could be jumping out which are the differences

Fourmi knows how to recompile, i did recompile but my binary doesn't work like fourmi's one

[Ricky1966]

@Fourmi If I could be helping?

[gagipro]

@Ricky1966 I tried to flash with the folder available in @ciotto repository : I have same results as Ciotto when I try to compile with @Fourmi repo (target MKS_TFT28_X2 in platformio.ini) or @ciotto repo (target BIGTREE_TFT35_V3_0 in platformio.ini) : the resulting flash directory behave like this : update never reboots and doesn't copy bmp files. the only thing that do work is the @ciotto directory : https://github.com/ciotto/BIGTREETECH-TouchScreenFirmware

[gagipro]

@Ricky1966 to recompile : you git clone any repo (fourmi ciotto or bigtree), you install platformio extension in vscode and you just click on build it will result in a firmware bin available in .pio/build/targetboard specified in plateformio.ini default_envs line

[gagipro]

@Ricky1966 git clone -b MKS-GD-TFT28-release https://github.com/ciotto/BIGTREETECH-TouchScreenFirmware.git -> to get the good branch

[Ricky1966]

@gagipro Thanks a lot!

[gagipro]

pffffiou finaly I managed to compile and have same behavior as @ciotto

and now I have this screen dudes !

of course it's unresponsive : we are probably missing pin mapping.

[gagipro]

@MirakelPrints I did what you suggested : commented bootlogo 👍 //#define SHOW_BTT_BOOTSCREEN

[gagipro]

[gagipro]

reset.txt allows to recalibrate BUT : no mapping so no luck

[Julian4Cats]

okay sorry to be that guy, but when i try and compile the source firmware for the genius pro i too get the error 1 message. Is there a fix available already? cuz i have been searching my ass off and still no results. i just need to enable host commands for octoprint lol

[gagipro]

I'm a (un)fortunated owner of an Artillery Genius Pro with GD32F305VC TFT screen.

I tried to do some tests and the reason why the original firmware update starts without issue is the name of the file.

In fact, if you try to update without the mkstft28evo.bin file, introduced by this commit, nothing happens, precisely like the update with this custom firmware.

This means that the update start only using the mkstft28evo.bin filename, but trying without more information can brick my LCD, so it's only a suppose.

The previous version of the board used an STM32F401RC MCU.

STM32F401RC and GD32F305VC are very similar MCUs, in fact both are Arm® Cortex®-M4 32-bit MCU, but somethings is different:

Check Features STM32F401RC GD32F305VC [x] MCU type M4 M4 [ ] Frequency 84 MHz 120 MHz [ ] Flash memory 256 KB 1024 KB [ ] SRAM 64 KB 96 KB Also, seems that the pinout is more or less the same:

So I can suppose that the board is more or less the same.

The good news is that the GD32F305VC is more powerful, the bad news is that probably requires a different compiled binary.

I'm not an expert, but probably I can try to add a new configuration to Platformio for MKS TFT28 Evo.

I think it's the 100pins package and not the 64 one, an exact pin to pin replacement.

[Ricky1966]

@gagipro 14 STM PA0 GD PD0- WKUP. Maybe this pin is different? For GD is a Wakeup pin when chip gone sleep? As @ciotto said, seems a problem of interrupts plotted on different pins. I downloaded from GD site a pdf with all type of chips, today a will do the same for STM. So I will look if there are differences of interrupts and what is the right corresponding from GD and STM. Which is the right model of STM32 to search?

[Ricky1966]

I know you have this uet, but if not Stm

[Ricky1966]

Amd this Gd

[gagipro]

For me its those chips :

[gagipro]

[gagipro]

But @ciotto said there is also

Which is a 64 pins package

Me I compared with the v1.0 version of the board and not the 1.2 stm version vs 1.2 gd version

[gagipro]

[gagipro]

I have difficulties to know what variant to use.

[gagipro]

ok understood the picture at begining of the thread is from the motherboard Ruby which is not good !!! it's stm32f107 vs gd32F305 and not a STM32F401 !!! anyway it doesn't change much the issue