MKS Robin TFT pins fixes for STM32 and STM32F1

[rhapsodyv]

Description

Update the TFT pins for the MKS Robin board after the TFT refactoring.

Fixed a few more issues on this board, for STM32F1:

• There's no SD_DETECT_PIN on MKS Robin V2.3 (Matt board). Only on > V2.4.
• Fixed touch on STM32F1 too

Benefits

Fix #20377
Fix #19274

Related Issues

#15474

[sjasonsmith]

@rhapsodyv now that the other PR is merged, is this ready to go?

Are these changes compatible with both STM32 and STM32F1 HALs?

[rhapsodyv]

@rhapsodyv now that the other PR is merged, is this ready to go?

Are these changes compatible with both STM32 and STM32F1 HALs?

Robin v1.1 is FSCM :-)

I didn't test it yet, but it would be easy to use FSMC displays on STM32, because we already have the code. Maybe we just some minor fixes.

[sjasonsmith]

I just want to be sure that merging this does not break existing functionality, since right now some board can be used on both HALs from different PIO environments.

[rhapsodyv]

I just want to be sure that merging this does not break existing functionality, since right now some board can be used on both HALs from different PIO environments.

I'm trying to test always on both STM32F1 and STM32, since the time I pushed the env:mks_robin_nano35_stm32. But the two HALs don't match in all features yet. At least in that PR, I tested both F1 and F4 and both HAL.

[tpruvot]

LCD_RESET_PIN & LCD_BACKLIGHT_PIN is only for non tft now... and the section altered is #if FSMC

[rhapsodyv]

LCD_RESET_PIN & LCD_BACKLIGHT_PIN is only for non tft now... and the section altered is #if FSMC

Yes, that caused the user issue. That pins file was outdated. I updated it to use TFT_** macros instead of LCD_** ones.

[rhapsodyv]

I'm just waiting the user test it, to merge. (or fix again hahah)

[AletheianAlex]

Just a note, not sure if it is directly related to this commit, but I happened to be testing TFT options with this most recent commit and inadvertently left unintended option enabled:

When enabling TFT_CLASSIC_UI while TOUCH_SCREEN is enabled in Configuration.h the build fails unceremoniously with several references to undefined XPT2046 related functions. A sanity check may clarify the situation to the user

[mattdog01]

@rhapsodyv Hello Victor thank you for your work. I downloaded a fresh copy of bugfix an 1hr ago and built the bin file and it is the same issue except I have also lost touch screen function. The display is visible in classic mode but not in colour UI mode. Touch screen doesn't work in either mode. I performed the build in the mks_robin environment not the mks_robin_stm32. I didn't have the build failure Alex reported. Configuration attached so you can see my craziness, I recommend getting children out of the room first, 32bit can be a bit scary.
Configuration.zip

[rhapsodyv]

Just a note, not sure if it is directly related to this commit, but I happened to be testing TFT options with this most recent commit and inadvertently left unintended option enabled:

When enabling TFT_CLASSIC_UI while TOUCH_SCREEN is enabled in Configuration.h the build fails unceremoniously with several references to undefined XPT2046 related functions. A sanity check may clarify the situation to the user

Can you share your configs? Which env are you using?

[rhapsodyv]

Just a note, not sure if it is directly related to this commit, but I happened to be testing TFT options with this most recent commit and inadvertently left unintended option enabled:
When enabling TFT_CLASSIC_UI while TOUCH_SCREEN is enabled in Configuration.h the build fails unceremoniously with several references to undefined XPT2046 related functions. A sanity check may clarify the situation to the user

Can you share your configs? Which env are you using?

@AletheianAlex I just compiled bugfix with classic ui with and without touch screen enabled, with no error.

[rhapsodyv]

@AletheianAlex I found the error when compiling TFT_CLASSIC_UI + TOUCH_SCREEN with mks_robin_nano35_stm32... I will fix it soon, the problem is that not all TFT options were ported to STM32 yet. And TFT_CLASSIC_UI is one of them. Soon I will push the fixes.

[rhapsodyv]

@rhapsodyv Hello Victor thank you for your work. I downloaded a fresh copy of bugfix an 1hr ago and built the bin file and it is the same issue except I have also lost touch screen function. The display is visible in classic mode but not in colour UI mode. Touch screen doesn't work in either mode. I performed the build in the mks_robin environment not the mks_robin_stm32. I didn't have the build failure Alex reported. Configuration attached so you can see my craziness, I recommend getting children out of the room first, 32bit can be a bit scary.
Configuration.zip

@mattdog01 you need to test the branch of this PR, not the bugfix. It wasn't merged yet.

[mattdog01]

@rhapsodyv sorry Victor. My misunderstanding. I try again. Which environment do you want me using? mks_robin?
I have a new fear, why did touchscreen stop working on the bugfix version from 3 days ago. Oh well that's a different problem.

[rhapsodyv]

@rhapsodyv sorry Victor. My misunderstanding. I try again. Which environment do you want me using? mks_robin?
I have a new fear, why did touchscreen stop working on the bugfix version from 3 days ago. Oh well that's a different problem.

mks_robin

About the touch, if it don't work, we will find out the reason. You can reach me on discord if you want.

[mattdog01]

@rhapsodyv Hello Victor the display is back to its color_UI glory once again. Thank you. Complied in mks_robin enviro. Touchscreen is not functioning. SO sad. Files attached. I'll open discord.
Configuration.zip

[rhapsodyv]

I'm waiting @mattdog01 final tests, to merge this.

[tpruvot]

please keep PF12 in comment at least, for current boards available...

[mattdog01]

@rhapsodyv @sjasonsmith Hello guys. Sorry this is so long.
I am very pleased to report that it would seem from the test that have been done over the last 24hrs that the problems on my board have been solved. I did the build using the mks_robin_stm32 environment and everything seems to work just fine. Focus was given to SD card reading, color_ui, touch function and buzzer function. No faults with the latest edits made by Victor. The issue of random print head motion to the end of an axis seems to be resolved as well. The build is very stable and works as expected. If there is any additional information or testing that you would like, please let me know and I will be very happy to help as I'm able. thanks again crew. So very much appreciate the work you guys/girls do.

Now to be a bit skeptical. It has happened in the past that a branch works great and the first bugfix after it is merged (I hope I am using the correct terminology) works great and then subsequent bugfixes stop working a short while later (the 2nd or 3rd one). Is there a way to prevent this from happening? Other than never download new versions or bugfixes, ;)
It was pointed out to me by Victor the there are 6 iterations of the MKS-Robin board. I'm aware of two of them v2.3 (mine) and v2.4 and even these two have some significant differences, that make them incompatible. Is there a way to preserve the version specific information (as requested by @tpruvot ) in the configuration files and the user can select which one they have? You may have a fix for this already but I'm just thinking of issues that may come up.

Last thing, this is likely not the place for this, but I want to run it by you guys to see if it is something think has merit. Would it be possible/practical to set up the configuration files with more individual files and group the functions into those files?
For example:
config_machine.h -all the physical setup of the machine itself. Bed size, accelerations, print and move speeds, etc.
config_boards.h
config_screen.h -settings for the user interface. Type of interface, style of display, calibration, etc.
config_bedlevel.h -method of bed leveling used and all the features related to that.
config_driver.h -driver settings for the Trinamic chips and all the trimmings, or any other type of driver setup.
config_multitool.h -to configure a machine with several print heads or tools that get swapped
config_octo.h -interface settings for octoprint (I have no idea if there are settings that would be needed)
config_MMU.h -for the Prusa multi-material unit
config_laser.h -for the folks that like to burn things with a laser print head
etc.etc.and then it is very expandible
Almost like a function or configuration abstraction layer if I understand abstraction layers (which I don’t)
Then if there was an update a person could go in and change only the configuration files they need to update for their machine and not get bogged down in the detail of growing configuration.h and configuration_adv.h files you have now. Maybe making it a little more user friendly in the end...maybe.
Thanks again everyone.

[AletheianAlex]

My apologies for lack of followup, we had a fire scare in the building and a medical emergency, so I lost my place in the two days of troubleshooting process. I repeated the testing with the version I pulled down at noon today (dec 09). I will download the absolute latest version and try the known bad configuration to see if the issue persists or if they are solved as with mattdog01 above, but here are my additional data points with bugfix from noon on dec 09 (and the versions from the previous few days that I tried):

PROBLEMS:

• under certain configurations of build ENV and UI, build will either not complete, or printer will manifest aberrant behavior for certain objects when printing from SD card i.e. toolhead 'wanders' during print: moving to bed limits, and/or retracing printed sections along the perimeter, and/or slowing to a crawl while extruder rapidly ejects filament, and/or freezes in place

HARDWARE :

• Board = MKS Robin Nano variant: Kingroon v1.2
• MKS tmc2225 drivers in 32x microstepping, standalone mode, all in stealth chop except the extruder
• SD card = verified genuine Samsung EVO plus (and several others)

METHODOLOGY:

• Settings were copied over from known-working configuration under latest stable release (2.0.7.2 Oct, 29). I will attach the config files (working version used mks_robin_nano35 env option in platform.ini, I have not tested other options such as STM32 Hal in stable release. I can follow up with those tests if requested).

• Bugfix branch Firmware compiled VIA VSCode+PIO and binary installed to printer VIA SD flash method, init EEPROM (m502+m500) VIA touchscreen menu, power-cycle printer: 30 sec off, confirm updated firmware, from SD card: print cube object and curved object with confirmed good slicer settings, at various speeds.

OTHER DATA POINTS:

• Printing VIA USB from Pronterface works fine
• Initiating SD card print VIA Pronterface and monitoring SD activity VIA m27 results in the same abnormal movement behavior as SD print initiated from LCD, but shows no abnormalities in the console
• Specific combinations and behaviors are listed below

Detailed configurations, actions, results:

Known good release and configuration: Oct29 release 2.0.7.2 with MKS_ROBIN_TFT24 screen, mks_robin_nano35 env, and TFT_COLOR_UI. Configuration copied over via DIFF tool and following variations tested:

#1) Bugfix branch @ noon DEC09 with mks_robin_nano35 and color UI = BAD: Wandering printhead on curved prints (worse on fast prints)
#2) Bugfix branch @ noon DEC09 with mks_robin_nano35_stm32 and color UI = GOOD

#3) Bugfix branch @ noon DEC09 with mks_robin_nano35 and classic UI = GOOD
#4) Bugfix branch @ noon DEC09 with mks_robin_nano35_stm32 and classic UI = BAD: won't compile

Actions for #4 that did not work:
-- purge pio and VSCode, cache, etc directories
-- close out project, rename folder, restart VScode, open new project
-- re-download bugfix (recent through DEC 09) branch and copy over settings via DIFF
-- reinstall relevant libraries and check for updates

RESULTS for #4 actions: the issue persists

Details of compilation error with the configuration #4 from the list at the bottom of this post (Classic UI + touch with mks_robin_nano35_stm32 env):

Linking .pio/build/mks_robin_nano35_stm32/firmware.elf
/Users/ACK/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: .pio/build/mks_robin_nano35_stm32/src/src/lcd/touch/touch_buttons.cpp.o: in function `TouchButtons::init()':
/Users/ACK/Desktop/Marlin-bugfix-2.0.x_DEC09/Marlin/src/lcd/touch/touch_buttons.cpp:46: undefined reference to `XPT2046::Init()'
/Users/ACK/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: .pio/build/mks_robin_nano35_stm32/src/src/lcd/touch/touch_buttons.cpp.o: in function `TouchButtons::read_buttons()':
/Users/ACK/Desktop/Marlin-bugfix-2.0.x_DEC09/Marlin/src/lcd/touch/touch_buttons.cpp:52: undefined reference to `XPT2046::getRawPoint(short*, short*)'
collect2: error: ld returned 1 exit status
*** [.pio/build/mks_robin_nano35_stm32/firmware.elf] Error 1

[failed]

It usually seems that this type of error is PIO/VSCode sleeping on the job with headers and can be fixed by closing out project, restarting VScode, and opening it in a new window, OR re-configuring a fresh download, but that doesn't have any effect. Various options can be made to compile by disabling touch screen interface, but I did not test the resulting binary

Actions for #1 that did not work:
-- All actions for #4 listed above
-- manually check for the existence of header files
-- adjust SDIO speed up and down
-- adjust buffers
-- adjust SPI speeds
-- with and without SD_CHECK_AND_RETRY
-- increase SDIO check retry up to 32 times
-- add 10uF capacitance to positive voltage rail filtering on board at SD card socket (existing = 0.1uF || 1uF)
-- Use various SD cards/formats/speed class/etc, low level reformatted with SD association tool
-- various combinations of planner features like LA, s_curve, adaptive stepping, JD, etc

RESULTS for #1: the issues persist: Low-capacity/low-speed SD card helped slightly. Other attempts were ineffective. Straight-line objects print fine regardless of speed (tried 10mm/S through 100mm/S). Curves objects all eventually fail VIA erratic toolhead behavior regardless of speed, complexity, and line segment count (although higher speed, complexity, and line segment count results in earlier failure)

Again, I will pull down and test #1 again with the most bleeding edge commits and report back.

Attached are the cnfigurations files for #1 (bug fix noon dec 09 with ENV mks_robin_nano35 env and TFT_COLOR_UI + touch enabled, as well as all other known-good settings from stable branch build) that served as the basis for the variations above. Changes from stock config are marked with the comment ACKCHANGED

config.zip

[rhapsodyv]

@AletheianAlex

1. Your problem seems related to tmc2225 + Linear Advance, that somehow is aggraved by a more complex UI. You should that a look on this SKR 1.4 with TMC2208 halts after moving axes back and forth with homing #20390 and others similar.
2. Classic UI isn't ready for STM32 envs yet. It's not a bug. The code wasn't ported yet.

Anyway, this issue is not about nano or tmc/lin_advance, but MKS Robin, that is a completely different board.

[AletheianAlex]

@rhapsodyv yes thank you. In follow-up, latest commits have solved the issue so I consider it closed. If it helps: Tmc22xx + Linear Advance with and without JD and s-curve are functional enough here on a daily basis when configured properly, and I noted that testing was done with and without to no effect regarding the immediate issues. I am aware of the lack of parity in the HAL and have been following its development since stm32duino. I apologize that I should have clarified initially: since there are a dozen Robin env, the post was a request to inform the user of a bad combination (the ini file can be daunting) and with the intent to follow up with other currently non-functioning configurations. But seeing mattdog01's post about a related issue I spent several days diagnosing I thought it useful for the thread and devs, as well as users searching the comments for help, to follow up publicly with relevant data points and additional configurations regardless of board extras since VE and ZE are similar enough in specs and differ only in a few GPIO pins and ADC channels, but the up to the minute bug fix commits have solved my issues as well, so it would seem that any differences were irrelevant. Thank you for the latest fixes.