Open jimmejames opened 3 years ago
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:
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 ?
But i dont know if its a hardware connection or software :(
It is both, IMO bad design choice by BTT that requires software UART code to be added.
BTW how do i add UART low-level driver code ?
One approach would be to implement similar code as used in Marlin, others could be searching the internet for ideas or come up with something from scratch. The easy part will be to send data as the TMC2209 is quite forgiving when it comes to the baud rate, a bit more tricky (I guess) would be to receive and decode data, at least one timer has to be used to time the bit transitions? And perhaps interrupts has to be disabled so that timing of the bit stream isn't disturbed too much?
Or maybe @fitch22 can help as it seems he has software serial working for BTT SKR-2 boards.
Here is an example how UART mode is implemented in a STM32F411 driver when a hardware UART is available and lowlevel UART driver code is available. It is the code inside#if TRINAMIC_ENABLE == 2209 ... #endif
blocks.
@jimmejames Did you resolve the A-axis issue? As I do not get a notification when a comment is edited I have not noticed your addition before now.
I just found this in Marlin but this stuff is out of my programing league. So i will wait if @fitch22 can get something to work and as backup plan i will order new drivers with SPI. https://github.com/MarlinFirmware/Marlin/blob/a185ce22cf6e4fb15250815c5c39318606a7e65a/Marlin/src/module/stepper/trinamic.cpp
@terjeio Unfortunately, no. I changed to GRBL and got all four working with that.
All, I believe I have the software serial stuff working now with skr-2 and tmc2209’s. However, what has taken so long is that the skr-2 has the ability to fry the tmc2209 drivers. According to BTT, this was only with a rev a board, but I have rev b as do others with the problem. I have just begun my analysis of the board design and root cause of the failures. I have managed to kill 9 of these guys and it is getting expensive:-). For now, I don’t think I would recommend anyone mixing tmc2209’s and the skr-2 until this is well understood.
There are several issues listed in the Bigtreetech GitHub site for the skr-2, some even with the 2208’s and there are links to Marlin issues, too.
I should have more information in a few days.
Bill
Sent from my iPad
On Oct 3, 2021, at 12:05 PM, drom89 @.***> wrote:
I just found this in Marlin but this stuff is out of my programing league. So i will wait if @fitch22 can get something to work and as backup plan i will order new drivers with SPI. https://github.com/MarlinFirmware/Marlin/blob/a185ce22cf6e4fb15250815c5c39318606a7e65a/Marlin/src/module/stepper/trinamic.cpp
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
@fitch22 So can you upload the code somewhere ? I would like to try it. I have SKR 1.4T not SKR-2 so it should be ok...
At this point it is STM32 only, but you might be able to modify it a bit to work with the LPC176x boards. If still interested, let me know.
Bill
From: drom89 @.> Sent: Sunday, October 3, 2021 3:01 PM To: grblHAL/LPC176x @.> Cc: fitch22 @.>; Mention @.> Subject: Re: [grblHAL/LPC176x] LPC176x Build Fails with TMC2130's (listed as experimental) (#5)
@fitch22 https://github.com/fitch22 So can you upload the code somewhere ? I would like to try it. I have SKR 1.4T not SKR-2 so it should be ok...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/grblHAL/LPC176x/issues/5#issuecomment-933032241 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQUGITMFAUB35BX6Y33GTLUFDHBVANCNFSM5BVAJBPQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . https://github.com/notifications/beacon/ACQUGITRNAIIJX5LFPLYP5LUFDHBVA5CNFSM5BVAJBP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOG6OPCMI.gif
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