LPC176x
LPC176x copied to clipboard
grblHAL
LPC176x Build Fails with TMC2130's (listed as experimental)
I'm getting the seventeen build errors listed below. Trying to build for a BTT SKR 1.4 Turbo with four TMC2130's. If I comment out the #define TRINAMIC_ENABLE 2130 in my_machine.h it builds just fine. This is from a current (Aug 5, 21) git recurse-submodules pull.
Description Resource Path Location Type c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-closer.o): in function_close_r': GRBL Driver LPC176x C/C++ Problem
c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-fstatr.o): in function _fstat_r': GRBL Driver LPC176x C/C++ Problem c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-isattyr.o): in function _isatty_r': GRBL Driver LPC176x C/C++ Problem
c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-lseekr.o): in function _lseek_r': GRBL Driver LPC176x C/C++ Problem c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-readr.o): in function _read_r': GRBL Driver LPC176x C/C++ Problem
c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-signalr.o): in function _getpid_r': GRBL Driver LPC176x C/C++ Problem c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-signalr.o): in function _kill_r': GRBL Driver LPC176x C/C++ Problem
c:/nxp/mcuxpressoide_11.4.0_6224/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.4.0.202103011116/tools/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v7-m/nofp\libc.a(lib_a-writer.o): in function _write_r': GRBL Driver LPC176x C/C++ Problem make: *** [makefile:40: Firmware.axf] Error 1 GRBL Driver LPC176x C/C++ Problem undefined reference to _close' GRBL Driver LPC176x line 0 C/C++ Problem
undefined reference to _fstat' GRBL Driver LPC176x line 0 C/C++ Problem undefined reference to _getpid' GRBL Driver LPC176x line 0 C/C++ Problem
undefined reference to _isatty' GRBL Driver LPC176x line 0 C/C++ Problem undefined reference to _kill' GRBL Driver LPC176x line 0 C/C++ Problem
undefined reference to _lseek' GRBL Driver LPC176x line 0 C/C++ Problem undefined reference to _read' GRBL Driver LPC176x line 0 C/C++ Problem
undefined reference to _write' GRBL Driver LPC176x line 0 C/C++ Problem
There is an incorrect library setting in release builds, should be like this:
I have a rather large overhaul of the Trinamic code in the pipeline, includes support for ganged motors and TMC2209 (UART mode). I need testers, can you help?
Yes, I'd love to help- have the time and hardware. FWIW- it's a custom built foam cutter (using standard ball screws) with end stops for the minimums connected to a BTT SKR 1.4 Turbo with four TMC2130's.
Also- the library change above worked great. I was able to build using the BL_0x4000 and my board accepted the files enough for Grbl HotWire Mega 5X (v5.02) to 'see' it, but I could not get it to move. More info than you asked, but wanted to give you an idea of my setup.
...but I could not get it to move
Try $4=7 (inverts stepper enable) possibly in combination with $338=7 (Trinamic driver enable). $338 is not available in all configurations, will return an error if not. Do you have the fourth axis (A) enabled or ganged/auto-squared motors?
Yes, I'd love to help- have the time and hardware
Great, I will switch over to a SKR 1.4 board during the weekend (with TMC5160 drivers) and check the basic stuff. When that is done I will upload the complete project and come back with a link for download.
I'm getting an error on my Grbl Hotwire:
So connecting to CNCJS running on a linux box and getting a different error: `CNCjs 1.9.22 [Grbl] Connected to /dev/ttyACM0 with a baud rate of 115200 ,1024|FS:0,0|Pn:PXYZRHS>
$ error:9 (G-code lock) $C error:8 (Not idle) ? <Alarm|MPos:0.000,0.000,0.000,0.000|Bf:35,1024|FS:0,0|Pn:PXYZRHS> ok GrblHAL 1.1f ['$' or '$HELP' for help] client> $$ [MSG:'$H'|'$X' to unlock] $0=10.0 (Step pulse time, microseconds) $1=25 (Step idle delay, milliseconds) $2=0 (Step pulse invert, mask) $3=0 (Step direction invert, mask) $4=0 (Invert step enable pin, boolean) $5=0 (Invert limit pins, boolean) $6=0 (Invert probe pin, boolean) $7=0 $10=511 (Status report options, mask) $11=0.010 (Junction deviation, millimeters) $12=0.002 (Arc tolerance, millimeters) $13=0 (Report in inches, boolean) $14=0 $15=0 $16=0 $17=0 $18=0 $19=0 $20=0 (Soft limits enable, boolean) $21=0 (Hard limits enable, boolean) $22=0 (Homing cycle enable, boolean) $23=0 (Homing direction invert, mask) $24=25.0 (Homing locate feed rate, mm/min) $25=500.0 (Homing search seek rate, mm/min) $26=250 (Homing switch debounce delay, milliseconds) $27=1.000 (Homing switch pull-off distance, millimeters) $28=0.100 $29=0.0 $30=1000.000 (Maximum spindle speed, RPM) $31=0.000 (Minimum spindle speed, RPM) $32=0 (Laser-mode enable, boolean) $33=5000.0 $34=0.0 $35=0.0 $36=100.0 $37=0 $39=1 $40=0 $43=1 $44=4 $45=3 $46=0 $47=0 $62=0 $63=2 $64=0 $65=0 $80=1.000 $81=0.010 $82=0.000 $84=0.000 $85=10.000 $90=0.000 $91=0.000 $92=0.000 $95=0.000 $100=250.000 (X-axis travel resolution, step/mm) $101=250.000 (Y-axis travel resolution, step/mm) $102=250.000 (Z-axis travel resolution, step/mm) $103=250.000 $110=500.000 (X-axis maximum rate, mm/min) $111=500.000 (Y-axis maximum rate, mm/min) $112=500.000 (Z-axis maximum rate, mm/min) $113=500.000 $120=10.000 (X-axis acceleration, mm/sec^2) $121=10.000 (Y-axis acceleration, mm/sec^2) $122=10.000 (Z-axis acceleration, mm/sec^2) $123=10.000 $130=200.000 (X-axis maximum travel, millimeters) $131=200.000 (Y-axis maximum travel, millimeters) $132=200.000 (Z-axis maximum travel, millimeters) $133=200.000 $140=500 $141=500 $142=500 $143=500 $150=16 $151=16 $152=16 $153=16 $200=22.0 $201=22.0 $202=22.0 $203=22.0 $210=50 $211=50 $212=50 $213=50 $338=0 $339=0 $341=0 $342=30.0 $343=25.0 $344=200.0 $345=100.0 $347=5.0 $348=2.500 $349=25.000 ok '$H'|'$X' error:9 (G-code lock)>`
Bear with me- I've used Marlin up until now, so Grbl is all new. Tried $4=7 && $338=7, but I think my error is upstream... currently working it.
I'm getting an error on my Grbl Hotwire:
Do you kow if the source available on github for this sender? Since it is based on Grbl Panel I believe I am able to patch it (I have patched Grbl Panel - but since it is archived I cannot create a PR).
grblHAL defaults to normally closed switches for safety reasons, try with $14=7 to invert the inputs. You migth also want to compile with compatibility level set > 0.
ioSender can be used to configure the controller, its Settings: Grbl tab is easy to use and has support for all the new settings in grblHAL.
Updated LPC176x project and ioSender are now available for download here.
LPC176x project tested with TMC2130 and TMC5160 drivers, the basic stuff works. Trinamic driver related settings and M-codes documented here.
FYI ioSender has a Trinamic tuner tab that can be used to plot live Stallguard result (load) and query driver status (M122), this is work in progress...
Cool- I pulled your files, created a new project in MCUXpresso, and only updated the number of axis in config.h, and then change to my SKR 1.4 and 2130's in my_machine.h and everything built great.
Starting with compatability_level 0 in config.h and it (effectively) works out of the box with ioSender! (sweet program btw!) I have something not quite right as 1) A/E0 doesn't spin (although it sounds like one of the motors is trying- I think maybe Z, but need to try again later today) and 2) my steps/mm aren't right as they done spin as far as they should (calibration issue I haven't looked at).
Right now, I have a 2130 populating X, Y, Z, and E0 (and motors are connected to the same). All are decoupled to individual Nema 17's. I run 24v power to the SKR and power the motors directly from the board- really just FYI as I'm not trying some very custom setup.
So far- this is awesome!
Edit- didn't answer your other question. The Grbl Hotwire is from here: https://rckeith.co.uk/file-downloads/ and the CNCJS is I think just an apt install from a Debian 10 (buster) terminal.
Edit 2: Played with it a little more and I see that nuts_bolts.h defines axis (such as the A_AXIS) as soon as N_AXIS > 3. This A axis is the only one that doesn't work and I've confirmed the points match what's in btt_skr_1.4.turbo_map.h to here: (https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/BTT%20SKR%20V1.4/Hardware/SKR-V1.4-Turbo-pinout.jpg) Here's the relevant part from my config.h:
// Compile time only default configuration
#ifndef N_AXIS
/*! Defines number of axes supported - minimum 3, maximum 6
If more than 3 axes are configured a compliant driver and map file is needed.
*/
#define N_AXIS 4 // Number of axes
#endif
#ifndef COMPATIBILITY_LEVEL
/*! Define compatibility level with the grbl 1.1 protocol.
Additional G- and M-codes are not disabled except when level is set to >= 10.
This does not apply to G- and M-codes dependent on driver and/or configuration settings disabled by setting level > 1.
<br>Set to 0 for reporting itself as "GrblHAL" with protocol extensions enabled.
<br>Set to 1 to disable some extensions, and for reporting itself as "Grbl".
<br>Set to 2 to disable new settings as well, use #define parameters for setting default values.
<br>These can be found in in this file and in defaults.h.
<br>Set to 10 to also disable new coordinate system offsets (G59.1 - G59.3) and some $# report extensions.
__NOTE:__ if switching to a level > 1 please reset non-volatile storage with \a $RST=* after reflashing!
*/
#define COMPATIBILITY_LEVEL 0
#endif
What am I missing?
What am I missing?
Have you set $7 and $338 to 15?
Edit- didn't answer your other question. The Grbl Hotwire is from here: https://rckeith.co.uk/file-downloads/ ...
Well, then I guess the source code is not available and I cannot make a PR.
Have you set $7 and $338 to 15?
When I try to move A, the X motor physically feels and sounds like it's energizing.
Note, I currently have my min limit switch reversed from the others so I will see the board is communicating with it. I forget if it's NC or NO, but the red square should go out when it is seen (I'm basing this on the operation of the others).
Here's my settings.txt from ioSender:
%
; grblHAL
; 1.1f.20210803
; [OPT:VNMSL,35,1024,4,0]
; [NEWOPT:ENUMS,RT+,TC,TMC=7]
; [FIRMWARE:grblHAL]
; [NVS STORAGE:*FLASH]
; [DRIVER:LCP1769]
; [DRIVER VERSION:210805]
; [BOARD:BTT SKR V1.4 Turbo]
; [PLUGIN:Trinamic v0.04]
;
$N0=M5G92X0Y350Z0F2500
$N1=
; 0 - Step pulse time
$0=10.0
; 1 - Step idle delay
$1=25
; 2 - Step pulse invert
$2=0
; 3 - Step direction invert
$3=3
; 4 - Invert step enable pin(s)
$4=15
; 5 - Invert limit pins
$5=15
; 6 - Invert probe pin
$6=0
; 7 - Disable spindle with zero speed
$7=0
; 10 - Status report options
$10=511
; 11 - Junction deviation
$11=0.010
; 12 - Arc tolerance
$12=0.002
; 13 - Report in inches
$13=0
; 14 - Invert control pins
$14=0
; 15 - Invert coolant pins
$15=0
; 16 - Invert spindle signals
$16=0
; 17 - Pullup disable control pins
$17=0
; 18 - Pullup disable limit pins
$18=0
; 19 - Pullup disable probe pin
$19=0
; 20 - Soft limits enable
$20=0
; 21 - Hard limits enable
$21=0
; 22 - Homing cycle
$22=0
; 23 - Homing direction invert
$23=0
; 24 - Homing locate feed rate
$24=25.0
; 25 - Homing search seek rate
$25=500.0
; 26 - Homing switch debounce delay
$26=250
; 27 - Homing switch pull-off distance
$27=1.000
; 28 - G73 Retract distance
$28=0.100
; 29 - Pulse delay
$29=0.0
; 30 - Maximum spindle speed
$30=1000.000
; 31 - Minimum spindle speed
$31=0.000
; 32 - Mode of operation
$32=0
; 33 - Spindle PWM frequency
$33=5000
; 34 - Spindle PWM off value
$34=0.0
; 35 - Spindle PWM min value
$35=0.0
; 36 - Spindle PWM max value
$36=100.0
; 37 - Steppers deenergize
$37=0
; 39 - Enable legacy RT commands
$39=1
; 40 - Limit jog commands
$40=0
; 43 - Homing passes
$43=1
; 44 - Axes homing, first pass
$44=4
; 45 - Axes homing, second pass
$45=3
; 46 - Axes homing, third pass
$46=0
; 47 - Axes homing, fourth pass
$47=0
; 62 - Sleep enable
$62=0
; 63 - Feed hold actions
$63=2
; 64 - Force init alarm
$64=0
; 65 - Probing feed override
$65=0
; 80 - Spindle P-gain
$80=1.000
; 81 - Spindle I-gain
$81=0.010
; 82 - Spindle D-gain
$82=0.000
; 84 - Spindle PID max error
$84=0.000
; 85 - Spindle PID max I error
$85=10.000
; 90 - Spindle sync P-gain
$90=0.000
; 91 - Spindle sync I-gain
$91=0.000
; 92 - Spindle sync D-gain
$92=0.000
; 95 - Spindle sync PID max I error
$95=0.000
; 100 - X-axis travel resolution
$100=640.000
; 101 - Y-axis travel resolution
$101=640.000
; 102 - Z-axis travel resolution
$102=640.000
; 103 - A-axis travel resolution
$103=640.000
; 110 - X-axis maximum rate
$110=500.000
; 111 - Y-axis maximum rate
$111=500.000
; 112 - Z-axis maximum rate
$112=500.000
; 113 - A-axis maximum rate
$113=500.000
; 120 - X-axis acceleration
$120=10.000
; 121 - Y-axis acceleration
$121=10.000
; 122 - Z-axis acceleration
$122=10.000
; 123 - A-axis acceleration
$123=10.000
; 130 - X-axis maximum travel
$130=200.000
; 131 - Y-axis maximum travel
$131=200.000
; 132 - Z-axis maximum travel
$132=200.000
; 133 - A-axis maximum travel
$133=200.000
; 140 - X-axis motor current
$140=1000
; 141 - Y-axis motor current
$141=1000
; 142 - Z-axis motor current
$142=1000
; 143 - A-axis motor current
$143=1000
; 150 - X-axis microsteps
$150=16
; 151 - Y-axis microsteps
$151=16
; 152 - Z-axis microsteps
$152=16
; 153 - A-axis microsteps
$153=16
; 200 - X-axis stallGuard value
$200=-234
; 201 - Y-axis stallGuard value
$201=-234
; 202 - Z-axis stallGuard value
$202=-234
; 203 - A-axis stallGuard value
$203=-234
; 210 - X-axis hold current
$210=50
; 211 - Y-axis hold current
$211=50
; 212 - Z-axis hold current
$212=50
; 213 - A-axis hold current
$213=50
; 338 - Trinamic driver
$338=15
; 339 - Sensorless homing
$339=0
; 341 - Tool change mode
$341=0
; 342 - Tool change probing distance
$342=30.0
; 343 - Tool change locate feed rate
$343=25.0
; 344 - Tool change search seek rate
$344=200.0
; 345 - Tool change probe pull-off rate
$345=100.0
; 347 - Dual axis length fail
$347=5.0
; 348 - Dual axis length fail min
$348=2.500
; 349 - Dual axis length fail max
$349=25.000
%
It looks like enabling the A-axis driver fails...
Are all motors listed when you press "Get status, all drivers" in the Trinamic tab? And has the status register content for the A motor at the bottom of the list a sensible value if so?
Set $37=15 to keep motors energized at all times. IMO at least the Z motor should be kept energized, at least if the spindle tends to move down due to gravity pull when deenergized.
Do the X-motor behave the same after?
If you have a voltmeter what is the voltage on the EN pin of the A driver? Should be 0.
I have checked the STEP, DIR and EN signals with a scope on the SKR 1.3 I have and they look ok, I will check with a fourth driver and a motor (if I can find one) later.
Hello,
No, the Trinamic tab doesn't appear if I start the ioSender program with Trinamic driver enabled for A. So I go to the Settings: Grbl tab and uncheck A from the Stepper Driver dropdown, then close and restart the program.
On the next load, "Get status, all drivers" works great for X, Y, and Z:
I then enable A and "Get status, all drivers" doesn't return anything:
Probably unrelated, but I didn't move the steppers between screenshots and the X and A positions show different values.
Ok, then UART communication fails for the A-motor. If communication fails for one none are enabled. I'll look into this later - I have some outside work to take care of.
Thank you! I'll experiment moving the 2130's and motor connections around to make sure there isn't something mechanically/electrically wrong.... trying to eliminate variables.
There is a typo here:
https://github.com/grblHAL/LPC176x/blob/d60e1331e6045ad213835fd2388d36486cb820ef/src/btt_skr_1.x.c#L166
should be:
cs_bit[A_AXIS] = TRINAMIC_CSA_BIT;
Same in line 172.
Perhaps fixing this will solve it... I am busy for a while more - perhaps you can check before I get to do it?
Much closer!
All steppers now report, but when trying to move A, X still tries to move and the limit switch (for A) isn't reporting correctly. My Z and A are setup identical (same 2130's and same steppers), so I swapped them to make sure it wasn't the hardware and same result. FWIW
I still get an "out of range" error with $7=15, but $338=15, and $37=15 work. $37=15 gives an audible motor-holding noise on just my Z axis.
Edit- held the wife & kids up from photos to test this- so I'll play with it some more tonight when we get back.
I still get an "out of range" error with $7=15
My bad, should be $4=15...
A (and B) limit inputs are not read as it should here: https://github.com/grblHAL/LPC176x/blob/d60e1331e6045ad213835fd2388d36486cb820ef/src/driver.c#L559-L563 Add after line 562:
#ifdef A_LIMIT_PIN
signals.min.a = DIGITAL_IN(A_LIMIT_PORT, A_LIMIT_BIT);
#endif
I have now tested with a SKR v1.3 board and all axes are working, why not for the v1.4 board I do not know as the pin mappings are according to the schematic. Could be due to $4 not set to 15?
Edit: FYI the low level comms code for the drivers do not support ganged axes - I'll fix that tomorrow.
That 562 addition fixed the limit switch! Thank you!
Maybe back to a hardware issue? Maybe I'm plugged into the wrong ports?!? I'm plugged into E0 for A.
Maybe I'm plugged into the wrong ports?!? I'm plugged into E0 for A.
That is the correct port.
Voltage on the EN pin should be checked. Is it 0V during motion?
Confirmed at ~0VDC on E0's EN-GND (matches that on Z's similar pins). By comparison, my E1's EN-GND is just shy of 4VDC.
Edit- some additional info. While the heat sinks on X, Y, & Z drivers are warm (I'd guess 50-60C, but will find my IR temp probe), the A driver is cold.
Also, I have three TMC5161's around here that could be used if you think diagnosing with an additional driver would help. Unfortunately, I don't have access to another 2130 for a month or so.
Confirmed at ~0VDC on E0's EN-GND (matches that on Z's similar pins).
Good.
my E1's EN-GND is just shy of 4VDC
It is left floating so I guess that is ok.
the A driver is cold.
That is odd, the EN pin is always 0V and it still does not get warm? This indicates the motor coils are not energized for some reason. The A driver does not get initialized correctly? I see that your Stallguard settings ($20x) are outside the allowed range, can you try $RST=& to revert driver settings back to default?
Also, I have three TMC5161's around here that could be used if you think diagnosing with an additional driver would help.
IIRC they the same as 5160, just with lower RDSon MOSFETs? Meaning that the 5160 code can be used?
I've done a bit more refactoring of the driver and fixed a bug in ioSender (Get status for A-axis did not work) and uploaded the changes.
I've got reliable control of X, Y, Z, and all four end stops. No movement on A with the new ioSender:
Maybe nothing, but the MAC address of the A stepper seems off ending in 00:00.
Maybe nothing, but the MAC address of the A stepper seems off ending in 00:00.
It is the status register value, not a MAC address... The least significant 10 bits are the Stallguard sg_result.
Can you turn the A motor easily when EN is 0V? If you can then the motor is not energized as it should. Maybe a bug is somehow setting the A driver to freewheeling? Strange it is working with the SKR v1.3 board I have... Test by only enable the A motor ($338=8)?
Is VM (motor voltage) ok? (I guess it is since the A status register is non-zero).
Try inverting the A step output with $2=8 (or set it with Stepper > Step pulse invert in ioSender). The Step signal should go to 3.3V after you do that.
Measuring STP -> Gnd, I get the ~3V for the Z axis when I invert the set pulse, but ~0VDC on A with either it inverted or noninverted.
And yes, dead stick on A- no resistance.
~0VDC on A with either it inverted or noninverted.
Hmm, an error in the schematic? But it does not explain why the motor is not energized. Bad TMC2130? But it is working with Marlin?
Haha- I just swapped only the TMC2130's on Z and A and nothing was moving... forgot I had $338=8. Putting $338=15, I have the same issue, Z moves (with the 2130 I just pulled from A). I'll flip back to the Marlin code before. I think I only was getting 3 axis to work, but attributed that to software that wasn't designed to do, so I started looked at grbl. Let me circle back to it and make sure I can get all four to move with Marlin.
Edit- Just confirmed, I have all four axis working with Marlin (X, Y, Z, and E0)- based on this code: https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/tree/master/BTT%20SKR%20V1.4/Firmware/Marlin-2.0.x-SKR-V1.4-Turbo
Here are the files I changed: Marlin.zip
How can I add the 2209, the only options are 2130 and 5120 I swapped 2130 for 2209 as i see the 2209 hal is there but got a bunch of errors when it compiled .. thank you
How can I add the 2209
You have to add UART low-level driver code required. But does the board support UART mode Trinamic drivers? And if so is the UART pins connected to hardware UART capable MCU pins or must software UART code be implemented?
Hello, i have BTT SKR 1.4T with BTT TMC 2209. And cant get it working. For your question UART is working no problem with Marlin. But i dont know if its a hardware connection or software :(
The jumper setting is different from SPI mode: https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/BTT%20SKR%20V1.4/BTT%20SKR%20V1.4%20Instruction%20Manual.pdf
BTW how do i add UART low-level driver code ?
