grblhal / imxrt1062

grblHAL driver for NXP iMXRT1062 (Teensy 4.x)

iMXRT1062 Driver

A grblHAL driver for the NXP iMXRT1062 processor on a Teensy 4.x board.

Available driver options can be found here.

This driver can be built with the Web Builder, see Compiling for more information on building.

---

Important! There is a "bug" in Teensyduino prior to v1.54 that may cause periodic stalls in processing. It is possible that this is only happening when networking is enabled and then not always so.
Regardless of whether networking is enabled or not it is recommended that Teensyduino v1.54 is used to build this driver.

---

Networking plugin

The networking plugin is for Teensy 4.1 and needs the teensy41_ethernet lwIP library, updated to lwIP 2.1.3 and configured for grblHAL.

SD card plugin

The SD card plugin needs the uSDFS library, patched for bugs and configured for grblHAL.

---

Download the libraries above as zip files and add to your Arduino installation with Sketch > Include Library > Add .ZIP Library...

---

Board maps:

	N_AXIS	Ganged axes1	Ethernet	EEPROM	SD card	I2C Keypad	Encoders	Digital I/O	Analog I/O
Generic	3	no	no	yes2	yes	yes	-	-	-
BOARD_T40X101 for Teensy 4.0	max 4	max 1	no	yes2	no	yes	max 1	-	-
BOARD_T41U5XBB for Teensy 4.1	max 5	max 2	yes	yes2	yes	yes	max 1	4/3 or 1/33	-
BOARD_T41BB5X_PRO for Teensy 4.1	max 5	max 2	yes	yes (FRAM)	yes	yes	max 1	4/3 or 1/33	-
BOARD_GRBLHAL2000 for Teensy 4.1	max 5	max 2?	yes		yes	yes		4/?

¹ Each enabled reduces N_AXIS with one. Currently the board map file must be edited to enable ganged/auto squared axes.
² I²C EEPROM (or FRAM) is optional and must be added to the board. FRAM is recommended when the Odometer plugin is added to the build.
³ Number of digital input pins available is reduced when the Encoder plugin is added to the build.

Compiling

grblHAL can be built using the Arduino IDE or through the use of PlatformIO. Detailed directions may be found in the grblHAL wiki.

Arduino IDE

This driver compiles and uploads from the Arduino IDE and is partially dependent on the Arduino framework. Teensyduino is required and must be added to the Arduino IDE.

See the Wiki-page for compiling grblHAL for instructions for how to import the project, configure the driver and compile.

PlatformIO

About

PlatformIO is a cross platform build system for embedded systems. It provides both a GUI (delivered as an extension for VSCode) as well as a command line interface, both of which wrap the underlying toolsi (scons, gdb, etc). It features library management, a robust interface for dynamic builds and scripting, and a set of Python APIs for customization. Users interested in exploring complex project configurations utilzing many vendor provided hardware abstraction layers, processor specific customizations, etc may consult the configurations used within the Marlin project (configurations may be found in platformio.ini and ini/*).

Quick Start

Compiling grblHAL with PlatformIO is quite trivial. PlatformIO will handle setting up any processor/architecture specific tooling needed to compile and flash grblHAL. To begin, decide whether you are choosing to use the GUI via VSCode or the command line tooling. Consult the documentation for directions on installing in the desired manner.

Next we will clone this repository, ensuring that all submodules have been retrieved:

git clone --recurse-submodules https://github.com/grblHAL/iMXRT1062.git

Next, change into the grblHAL_Teensy4 sub-directory located within your checkout of the project (by default this would be iMXRT1062/grblHAL_Teensy4).

This directory contains the platformio.ini configuration file. Within the configuration file we have some basic boilerplate information specifying how to build the project. These settings describe:

• The board we desire to compile for (the Teensy 4.0 or 4.1) Note: Both boards are defined in platformio.ini. The primary distinction between the boards is the onboard flash size (1.94MB in the Teensy 4.0 and 7.75MB in the Teensy 4.1). While either environment will generally work, using the wrong environment may raise errors in the future if the build sizes become too large.
• The platform to be used (Within PlatformIO a development platform is described as "a particular microcontroller or processor architecture that PlatformIO projects can be compiled to run on. (A few platforms, for example Teensy, use different target architectures for different boards.)"
• The framework we will use for development (For the Teensy we use arduino. Examples of other frameworks inclue CMSIS, FreeRTOS, STM32Cube, etc).
• A working environment which scopes specific configurations for the tools pio run, pio test, pio check, pio debug, and any custom targets which may be defined. Our environment re-uses the board name, teensy41 and sets this value as the default environment.
• Any 3rd-party libraries we may need (e.g. uSDFS, Ethernet, etc)
• How assets should be flashed to the device (The teensy-cli application)

The configuration file also provides a number of configuration abstractions where common configurations can be applied project wide or by build environment. For more information on customizing your configuration or build environment, consult the PlatformIO documentation.

Next, make any desired edits to the file src/my_machine.h

Begin compilation by running the command:

pio run

This will begin the compilation, using the default environment. Alternate environments may be specified using the flag -e/--environment. Additional targets may be viewed by running pio run --list-targets. Changing the target from the default (compilation) can be done using the flag -t/--target (e.g. pio run -t clean).

As the compilation begins all of the needed tooling and libraries will be retrieved. Tooling will be installed to the user's "global" PlatformIO installation. Project specific libraries will be stored in the subdirectory .pio. The .pio directory is solely used for temporary build artifacts and caching libraries. It is safe to completely remove and will be re-created on the next execution of pio run.

At the end of compilation, two assets will be generated:

• .pio/build/teensy41/firmware.elf
• .pio/build/teensy41/firmware.hex

Our ELF (Executable and Linkable Format) binary contains the full set of headers desribing our program and section headers. Our HEX file is the binary rendering of solely the data section of the ELF file. The HEX file is the one used by the default Teensy tooling. The ELF file is useful when performing debugging (i.e. through the use of gdb or openocd).

We may use the target upload to flash our new firmware. The default project-specific configuration in platformio.ini utilizes the Teensy CLI application. A complete list of supported upload protocols for the Teensy 4.1 (e.g. teensy-gui, jlink) can be referenced on the Teensy 4.1 page in the PlatformIO documentation.

To execute our upload, run the following command:

pio run -t upload

Congratulations! You should now have a newly flashed Teensy running grblHAL!

Updating your check-out

To update your checkout in the future, ensure that all git submodules are updates along with the primary repository:

git pull --recurse-submodules

---

2023-09-20

imxrt1062's Issues

GrblHAL Hangs if EEPROM is not present - iMXRT1062

If the code is built for EEPROM and you boot without the EEPROM attached, the program does not respond to the USB serial port and appears to be hung.

This was an issue because the EEPROM is located on the breakout board but it is more convenient for me to build and load code with the Teensy out of its socket. I spent an hour debugging before I realized my error. Dumb, I know, but an error code would have been helpful. The same thing will presumably happen if the EEPROM becomes defective so it would be more generally useful than just my corner case.

I would suggest a code or message that resolves to something like "EEPROM not found" so it is clear that the build and load were successful even though the EEPROM is missing. If you will assign a new numeric code I'll make a pull request and make the required changes.

Question: Why is it an error to use a pin other than 12 or 13 for SPN PWM?

Why is it an error to use a pin other than 12 or 13 for Spindle PWM?

https://github.com/grblHAL/iMXRT1062/blob/0b109fbf186890b9e1febedc92b650062ee97734/grblHAL_Teensy4/src/driver.h#L187C10-L187C10

Z-probe support?

Hi, does grblHAL support different probes for auto set z-height (auto focus) ?

I have a laser with x,y and Z (+rotary)

I`m interested in a function to auto set focus height for the laser

I could mount a simple switch at the laser module that is triggered when it hits the material surface and then set the focus distance in software.

one alternative is to configure this switch as an z-end stop and home the z-axis when I add a new object to engrave..

Or is there probe support that can handle this? like a button that triggers a macro that probes the surface and sets the focus?

error: 'msSCSICapacity_t' does not name a type msSCSICapacity_t msCapacity;

Error on compile with fresh clone.

Windows 10 Pro 20H2 build 19042.1165
VSCode 1.60.0
PlatformIO IDE v2.3.3
Teensy 4 v4.12.0
Python v3.9.7:1016ef3

STR:
git clone --recurse-submodules https://github.com/grblHAL/iMXRT1062.git
In PlatformIO terminal>pio run

`Compiling .pio\build\teensy41\lib7a0\uSDFS\ff.c.o
In file included from .pio\libdeps\teensy41\MSC-non-blocking\src\msc.h:31:0,
from .pio\libdeps\teensy41\MSC-non-blocking\src\MassStorageDriver.cpp:29:
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2045:2: error: 'msSCSICapacity_t' does not name a type
msSCSICapacity_t msCapacity;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2046:2: error: 'msInquiryResponse_t' does not name a type
msInquiryResponse_t msInquiry;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2047:2: error: 'msRequestSenseResponse_t' does not name a type
msRequestSenseResponse_t msSense;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2048:2: error: 'msDriveInfo_t' does not name a type
msDriveInfo_t msDriveInfo;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2067:31: error: 'msSCSICapacity_t' has not been declared
uint8_t msReadDeviceCapacity(msSCSICapacity_t * const Capacity);
^
compilation terminated due to -fmax-errors=5.
In file included from .pio\libdeps\teensy41\MSC-non-blocking\src\msc.h:31:0,
from .pio\libdeps\teensy41\MSC-non-blocking\src\MassStorageHost.cpp:31:
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2045:2: error: 'msSCSICapacity_t' does not name a type
msSCSICapacity_t msCapacity;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2046:2: error: 'msInquiryResponse_t' does not name a type
msInquiryResponse_t msInquiry;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2047:2: error: 'msRequestSenseResponse_t' does not name a type
msRequestSenseResponse_t msSense;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2048:2: error: 'msDriveInfo_t' does not name a type
msDriveInfo_t msDriveInfo;
^
C:\Users\gawyn.platformio\packages\framework-arduinoteensy\libraries\USBHost_t36/USBHost_t36.h:2067:31: error: 'msSCSICapacity_t' has not been declared
uint8_t msReadDeviceCapacity(msSCSICapacity_t * const Capacity);
^
compilation terminated due to -fmax-errors=5.
*** [.pio\build\teensy41\libac5\MSC-non-blocking\MassStorageDriver.cpp.o] Error 1
*** [.pio\build\teensy41\libac5\MSC-non-blocking\MassStorageHost.cpp.o] Error 1
========================================================================================= [FAILED] Took 16.48 seconds =========================================================================================

Environment Status Duration

---

teensy41 FAILED 00:00:16.481
==================================================================================== 1 failed, 0 succeeded in 00:00:16.481 ====================================================================================`

SD Card support

What would the SD Card typically be used?

Is it for storing and running g-code programs? If so how would it be accessed from Gcode Sender?

laser co2 + diodo

Salve, accanto alla testa laser ho montato un laser diodo 445nm. gestisco l'unica uscita pwm del mks dlc32 mediante interruttore on-off-on e commuto tale uscita o su co2 oppure su diodo. ora che ho comprato la T41U5XBB (ancora in viaggio) ho tante uscite pwm e potrei gestire diversamente la cosa, oltre al problema dell'offset fra i due utensili. come potrei fare per commutare da software sia il cambio utensile (e relativo pin pwm) e impostare un offset per il secondo utensile? p.s. se accendo il diodo con l'interruttore commutato su co2 avrò un'uscita laser (diodo) al 100%, stessa cosa se commuto l'interruttore su diodo e accendo il co2...co2 al 100%.

Hello and I have Been Known to Misinterpret Ideas

Hello,

I know this is silly. I have a grblHAL board with Teensy4.1 attached and everything soldered in via the instructions...

1. I was moving the motors the other day by hand
2. I was receiving negative feedback on the controller
3. Is reverse polarity due to manual motor movement not collective with the grblHAL board and Teensy4.1 attachment?

I am asking only because I am terrible with the controls so far. I am still learning slowly.

So, this is what happens.

I move the axis, X and/or Y, manually and I can see the light on the board light up. Should I take the motors and detach them before handling manual motor movement?

I know it is silly to ask but some reverse polarity protection would be okay with me.

Seth

P.S. If this is uncalled for currently and the build does not require it, okay. I understand and I will fully agree to unplug things before handling manual movement. It just spooked me! So, I thought I would bring it up. Just a heads up for you or anyone really who likes this boards, like me, and who uses them to alter machinery.

If there is reverse feedback control on the board itself so things do not get fried a bit, okay. 

I must have missed something while soldering the board and the attachments. Anyway, keep up the good work and do not quit.

I know what you do works. I am not saying it does not work. I fired the laser the other day. It works! And for that, I am thankful.

I am still practicing the cartesian build with my cheap-o, depot machine I picked up for $99.99. So, my dilemma may be the motors or the grounding of the entire system. I will try to keep everyone updated once I configure things. This way, I can be of some assistance when you guys keep going!

QEI_ENABLE causes build errors.

Several people have run into this and I can reproduce in Arduino/Teensyduino environment.

Uncommenting #QEI_ENABLE in my_machine.h causes. Using the most recent src/encoder. Commenting it out allows build to complete and resulting .hex file runs on Teensy 4.1.

Immediate cause seems to to be missing structure member (enqueue_realtime_command). Below are the first two error messages.

D:\Documents\Arduino\libraries\grblHAL_Teensy4\src\encoder\encoder.c: In function 'reset_override':
D:\Documents\Arduino\libraries\grblHAL_Teensy4\src\encoder\encoder.c:215:23: error: 'io_stream_t {aka struct }' has no member named 'enqueue_realtime_command'
hal.stream.enqueue_realtime_command(CMD_OVERRIDE_FEED_RESET);
^
D:\Documents\Arduino\libraries\grblHAL_Teensy4\src\encoder\encoder.c:219:23: error: 'io_stream_t {aka struct }' has no member named 'enqueue_realtime_command'
hal.stream.enqueue_realtime_command(CMD_OVERRIDE_RAPID_RESET);
^

REQ: Add serial driver information for Serial8 on Teensy 4.1 as used in grblHAL2000 controller board

As this happened within another issue that is appropriately now closed, and it is specific to Teensy based boards, I thought I should tow this over here. Serial 8 has been working well with these changes:

I am happy to report the dragon has been slayed:

Port /dev/ttyAMA0, 21:38:24
Press CTRL-A Z for help on special keys

GrblHAL 1.1f ['$' or '$HELP' for help]

Here is the entry I created for Serial8 on the Teensy 4.1. I apologize for not submitting a patch but I think it best someone who really understands it and how to add it to the desired structure make the necessary changes so it can coexist with various board/pin combinations:

// JAC adjusted per https://github.com/PaulStoffregen/cores/blob/master/teensy4/HardwareSerial8.cpp
// Applies to grblHAL2000 board.  Serial8 is routed to the 40 pin Pi format expansion header on the board

static const uart_hardware_t uart5_hardware =
{
    .port = &IMXRT_LPUART5,
    .ccm_register = &CCM_CCGR3,
    .ccm_value = CCM_CCGR3_LPUART5(CCM_CCGR_ON),
    .irq = IRQ_LPUART5,
    .irq_handler = uart_interrupt_handler,
    .rx_pin = {
        // .pin = 21,
        .pin = 34, // JAC For connection to Pi Header
        .mux_val = 1,
        .select_reg = &IOMUXC_LPUART5_RX_SELECT_INPUT,
        .select_val = 1
    },
    .tx_pin = {
        // .pin = 20,
        .pin = 35, // JAC for connection to Pi Header
        .mux_val = 1,
        .select_reg = &IOMUXC_LPUART5_TX_SELECT_INPUT,
        .select_val = 1
    }
};

Any chance to add one more axis to make it 6 axis?

I have a project that would greatly benefit from 6 axis.

calo improvviso emissione fascio laser / pwm

Salve, oggi stavo facendo una lavorazione su 3 livelli colore di lightburn, 1° livello foto modalità stucki, 2° riempimento di contorni e 3° taglio. Il problema si presenta dopo aver fatto perfettamente la foto, finisce la foto e passa al riempimento. Effettua si e no 20 linee di riempimento, impostato a 8000mm/min 20% 0.08 linee per millimetro, e all'improvviso mi accorgo che il laser si muove ma non ho emissione di fascio, l'amperometro da 0-30mA segna forse 2 e nel plexiglass si vede che il riempimento non c'è. Blocco tutto, rifaccio l'homing, seleziono soltanto 2° livello-riempimento e 3° livello-taglio e porto a termine il lavoro. Utilizzo teensy4.1+T41U5XBB. Non riesco a capire da cosa può dipendere tutto questo, la macchina funzionava prima e funzionava anche dopo, è come se il controller abbassa, ma non azzera, l'uscita pwm, dopo l'homing (senza toccare altro, tipo spegnere e rieccendere ecc...) tutto funziona come prima. Anche la temperatura era nel range valido e segnava 13.4 °C

Not an issue: I want to know MODBUS implementation.

Hi @terjeio
I want to implement MODBUS communication for my delta MS300 VFD. I want to know:

1. Can Modbus TCP work simultaneously when ethernet is main communication channel? I can connect teensy to network router for connecting different devices.
2. If not option 1, how to enable modbus RTU over serial communication to use GPIO 0 & 1 on teensy 4.1?
3. Any other points to keep in mind to setup in VFD and grblHAL.
   Thanks in advance,
   Ravi

unknown type name 'io_stream_properties_t

Get an error when trying to compile current version
"uart.c: 184:8: error: unknown type name 'io_stream_properties_t"

Can not seem to find where it should be defined?

USB host support

Hi @terjeio
I was wondering if I can activate native USB host of teensy4.1 and use it as secondary source to read programs from a usb pen drive in addition to sd card. I hope it should be easy. I use PIO for compilation. Can you guide me through the process on which library to include for it and how to host its space alongwith sd on server (including ftp).
Thanks in advance and a big salute for whatever you have done for the DIY CNC community.
Regards,
Ravi

File not found : altpc.h

Error on compiling using VSCode and PlatformIO
Cannot find file altpc.h

src\networking\httpd.c:104:24: fatal error: lwip/altcp.h: No such file or directory

Careful exploration of grblHAL folders and .pio/libdeps confirms the file does not exist.

valore ottimale planner $398

Salve, ho provato ad aumentare il planner del pianificatore a $398=1000 e un'immagine in scala di grigi eseguita a 40000/min veniva eseguita ad una velocità maggiore (molto maggiore) rispetto a 40000/min e $398=35, ma ottengo un'immagine (in scala di grigi) molto confusa, come se il laser rimanesse acceso più a lungo e sincronizzato (impulso e passi) male. Utilizzo anche il plugin LB cluster. Con quali altri parametri potrei giocare per avere un'immagine migliore? utilizzo teensy4.1 + T41U5XBB

Swapping spindle PWM pin from 13 to 12 breaks comapilation

Hi @terjeio
As I have shown interest to use teensy4.1 onboard LED as status light with blink patterns, I considered to use GPIO 12 for spindle PWM. But I can't compile that way with following messages in PIO.

Executing task in folder grblHAL_Teensy4: platformio run <

Processing teensy41 (board: teensy41; platform: teensy; framework: arduino)

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https://docs.platformio.org/page/boards/teensy/teensy41.html
PLATFORM: Teensy (4.12.0) > Teensy 4.1
HARDWARE: IMXRT1062 600MHz, 512KB RAM, 7.75MB Flash
DEBUG: Current (jlink) External (jlink)
PACKAGES:

• framework-arduinoteensy 1.153.0 (1.53)
• toolchain-gccarmnoneeabi 1.50401.190816 (5.4.1)
  LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
  LDF Modes: Finder ~ chain, Compatibility ~ soft
  Found 93 compatible libraries
  Scanning dependencies...
  Dependency Graph
  |-- 1.1.2+sha.52b0ae3
  | |-- 1.0.0+sha.5a2e6f4
  | | |-- <USBHost_t36> 0.1
  |-- 1.0.0+sha.5a2e6f4
  | |-- <USBHost_t36> 0.1
  |-- 2.0.2+sha.58c266f
  |-- 2.0.2
  Building in release mode
  Compiling .pio/build/teensy41/src/driver.c.o
  Compiling .pio/build/teensy41/src/grbl/alarms.c.o
  Compiling .pio/build/teensy41/src/grbl/coolant_control.c.o
  Compiling .pio/build/teensy41/src/grbl/corexy.c.o
  src/driver.c: In function 'spindle_set_speed':
  src/driver.c:1177:24: error: 'settings_t {aka struct }' has no member named 'sp'
  if(settings.sp)
  ^
  In file included from src/driver.c:87:0:
  src/driver.c: At top level:
  src/grbl/motor_pins.h:692:13: warning: 'motor_iterator' defined but not used [-Wunused-function]
  static void motor_iterator (motor_iterator_callback_ptr callback)
  ^
  *** [.pio/build/teensy41/src/driver.c.o] Error 1
  ======================================= [FAILED] Took 6.62 seconds =======================================

Environment Status Duration

---

teensy41 FAILED 00:00:06.622
================================= 1 failed, 0 succeeded in 00:00:06.622 =================================
The terminal process "platformio 'run'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

LATHE Y to Z

How can I change Y to Z for lathe.
config is ioSenderEdge2.041p8
board_T41U5XBB_SS and IMXRT1062 (update Jan 2023)
Thank you

Bluetooth for Android sender

Can I hookup a hc-05 module to tx rx for serial communication?

Do I need to modify the code?

Thank you in advance

Teensy crashes with LITTLEFS

Dear All,

Teensy crashes immediately after booting up when either LITTLEFS_ENABLE or WEBUI_ENABLE is set. The controller becomes inaccessible over USB or Ethernet. I used Arduino 1.8.19 and Teensyduino 1.57 to build grblHAL. Everything seems to work normally when these two plugins are disabled.

Thank you.

Error in GRBLHAL2000_map.h file

Hello.
On the GRBLHAL2000 controller, pin 38 is used to output AUXOUTPUT3_PIN.
In the GRBLHAL2000_map.h, pin 12 is used.

Teensy40 Unable to connect

changing in my_machine.h :
#define BOARD_T40X101
//#define BOARD_T41U5XBB

and leaving the following commented out:
//#define USB_SERIAL_CDC 2
OR setting it to
#define USB_SERIAL_CDC 2

Compiling with PlatformIO Uploading with Teensy Loader 1.54

Used both FTDI-Driver and built in Microsift Serial Driver on Win10 to test, both configured to 115200 8N1.
Used UGS and PUTTY to test connection.

Using the ethernet port

Does software like LightBurn support using the Ethernet as an alternative to USB?

Or is the ethernet support for webui only?

Can I add the 7th and 8th axis support.？

I checked part of the source code and found that there are definitions of U-axis and V-axis in many places. I try to imitate the programming, add the U-axis and v-axis code where there is ABC axis code, simply and completely imitate the macro definition and variable declaration of ABC axis. Unfortunately, although I have checked it many times to make sure that the U-axis and V-axis codes have been added to all places with ABC axis codes. The compilation can pass smoothly without any errors, and it can also be downloaded to teensy4.1 normally. But when I try to control with the serial assistant, the MCU microcomputer didn't respond at all, and the USB serial port of the computer was constantly lost and reconnected. This shows that the MCU is constantly restarting. There must be something wrong. I think grblHAL should definitely support 8 or 9 axes running at the same time. What should I do?

error:2 - Missing the expected G-code word value or numeric value format is not valid.

I get this error randomly in code.

Currently streaming through USB, I have to test with a SDCard to see if it's related to the USB.

Happens randomly in cycle, not always the same place.

Last time the error happened here, in the middle of a cut:

5179	ok	N51720 X114.298 Z-4.961
5180	ok	N51730 X114.458 Z-5.323
5181	ok	N51740 X114.571 Z-5.649
5182	ok	N51750 X114.663 Z-6.015
5183	ok	N51760 X114.719 Z-6.398
5184	error:2	N51770 X114.736 Z-6.754
5185		N51780 X114.635 Y31.872 Z-6.847
5186		N51790 X114.615 Z-6.452
5187		N51800 X114.58 Z-6.201
5188		N51810 X114.51 Z-5.877
5189		N51820 X114.406 Z-5.535
5190		N51830 X114.35 Z-5.388

Initial test of webui, ftp and SD

Hi @terjeio ,
Just wanted to share my initial impressions after playing some time on webui, ftp and sd.

1. FTP works like a charm
2. Uploading/deleting files from sd via webui and ftp both works perfect.
3. Webui is not responding to any manual command entry in the text box area.
4. Cant run program from webui.
5. No state or coordinate updates in webui.
6. When I reload webui in browser, it hangs and doesnt show up any data.

It seems, webui is still under initial development. I want to know how I can map html, css, js project to internal bindings. I mean, how to host a server, send commands to serial console using webpage, so that I csn design my own app.

z-axis TLO and probing report with bCNC

Trying to chase down two issues interfacing with bCNC (building with Arduino 1.8.19 IDE):

1. The TLO default report setting in grbl/config.h lists Z-axis as the default. Without changing config.h, the TLO report includes XYZ coordinates (for a three axis machine), bCNC is expecting only the Z coordinate, so the TLO always gets set to 0.0 (the X-axis value). I have changed config.h in my local version to only report the Z-axis and have modified bCNC to accept any number of axis. This one I have solved, but how would I select the Z-axis TLO report in your new build system?
2. When bCNC performs an autoleveling scan, it issues a G38.2 command and waits for its completion. Apparently, it expects a PRB response but in my grblhal version none is given. I can force a response using $#, by modifying bCNC, but I thought this was planned for. Is there a way to get a PRB response on the completion of the probe? I have tried several ways of changing DEFAULT_REPORT_PROBE_COORDINATES, but still don't receive a PRB response on the probe completion. Any tricks I can try?

Haven't tried the new build system yet, would it be able to accommodate these types of customization's?

How to add new pins and use them.

Hello,
I would like to use pins 48-50 (Teensy 4.1 from PSRAM) in the programme, how do I set this up?

Spindle sync compile error

Hello,

I am getting an error here when compiling with spindle_sync enabled

iMXRT1062/grblHAL_Teensy4/src/driver.c

Lines 1494 to 1495 in dc680ff

	if((hal.spindle.get_data = (hal.driver_cap.spindle_at_speed = settings->spindle.ppr > 0) ? spindleGetData : NULL) &&
	(spindle_encoder.ppr != settings->spindle.ppr || pidf_config_changed(&spindle_tracker.pid, &settings->position.pid))) {

I changed that line back to what it was in an older version and managed to get things working:
if((hal.spindle.get_data = settings->spindle.ppr > 0 ? spindleGetData : NULL) && (spindle_encoder.ppr != settings->spindle.ppr || pidf_config_changed(&spindle_tracker.pid, &settings->position.pid))) {

It's probably not the perfect fix and would be worth someone having look at it.

Limit switch/sensor issues and Homing

Recent build (source updated July 3). I have NO sensors (NPN Prox) so inverted limit pins ($5=15). They work, I get Alarm 1 when hard limits are enabled and a is sensor triggered. However, homing does not work. When I start homing, the first Axis (Z) moves a short distance and throws an Alarm 8. Individual axis homing ($HX, $HY, $HZ) does the same thing - short move then alarm. I believe it related to how NO sensors are handled.

I have tested this on a bare teensy with T41U5XBB_map.h and T41BB5X_map.h selected from my machine. Both behave the same. I first found this while testing homing on my Avid Pro4848 running grblHAL on the T41ProBB board..

It looks to be correctly working with $5=0, i.e. NC sensors. With the limit pins not connected to ground (i.e. open and thus triggered), I get this:

<Idle|MPos:0.000,0.000,0.000,0.000|Bf:35,1023|FS:0,0|Pn:PXYZA>

and if I short a limit pin to ground, say X, I will get

<Idle|MPos:0.000,0.000,0.000,0.000|Bf:35,1023|FS:0,0|Pn:PYZA>

and the Signal "LED" in ioSender will go off.

However, with $5=15, i.e. NO sensors and no limit pins shorted to ground (i.e. not triggered), I get:

<Idle|MPos:0.000,0.000,0.000,0.000|Bf:35,1023|FS:0,0|Pn:PXYZA>

Thus saying that all the limit inputs are triggered - they are not. With hard limits enabled the machine will run programs just fine. If I short a limit pin to ground there is no change in the idle message but an Alarm 8 is thrown. So, even though grblHAL does not report a change in the limit sensors, it does know to throw an alarm 8. This causes the problem for homing since it thinks the limit switch is already triggered?

The correct behavior should have the idle message show Pn:P (I have not dealt with the Probe yet) when no sensors are triggered. When a sensor is triggered the Pn: message should show the triggered Axis.

Here is the initial console info for the Pro board. For the original board, everything is the same except for BOARD:

[VER:1.1f.20210629:]
[OPT:VNMSL,35,1024,4,0]
[NEWOPT:ENUMS,RT+,ES,TC,ETH]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:210703]
[DRIVER OPTIONS:USB.2]
[BOARD:T41BB5X Pro]
[AUX IO:4,3,0,0]
[IP:0.0.0.0]
screen shot of Settings: Grbl

Enabling ethernet causes periodic stalls.

I think this may be related to an earlier report that never got resolved.

Using the current default distribution files, I build grblHAL for the T41U5XBB (set from my_machine.h) with USB_SERIAL_CDC 2 and nothing else enabled. Running it on a bare teensy 4.1, it works fine. When I enable Ethernet in my_machine.h, rebuild and run it on the same bare teensy I get "stalls". Going into console and checking verbose, one can see the reports being delayed.

The delays seem somewhat periodic. Typically 5 or 6 idle messages, delay, 1 idle message, delay and then it repeats. The delays seem to be a little longer than 2 seconds.

If I plug the teensy into a board with working networking hardware, I get the same behavior.

By the way, I was seeing this behavior in an older version of grblHAL [VER:1.1f.20210219:] but only with networking on the Pro build. I moved to the latest version and found it also happens with the T41U5XBB build. Enabling Networking caused the stalls. I deleted my previous grblHAL library and reinstalled the latest from scratch but get the same stall behavior for both the T41U5XBB and T41BB5X_PRO builds.

Edit: this is not sender related, I see the same behavior in a terminal app.

$i from working build:
[VER:1.1f.20210629:]
[OPT:VNMSL,35,1024,3,0]
[NEWOPT:ENUMS,RT+,ES,TC]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:210703]
[DRIVER OPTIONS:USB.2]
[BOARD:T41U5XBB]
[AUX IO:4,3,0,0]

$i from stalling build
[VER:1.1f.20210629:]
[OPT:VNMSL,35,1024,3,0]
[NEWOPT:ENUMS,RT+,ES,TC,ETH]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:210703]
[DRIVER OPTIONS:USB.2]
[BOARD:T41U5XBB]
[AUX IO:4,3,0,0]
[IP:0.0.0.0]

Controller hardlocks after Invalid G-Code Command when using Ethernet connection

Controller:
Teensy4.1 on grblHAL2000 Board
Firmware:
https://github.com/Expatria-Technologies/iMXRT1062/releases/tag/v1.03
ioSender: 2.0.40 (latest from Jul. 18)

Issue:
When issuing a wrong G-Code Command (e.g.: G1 x200,1) the controller hardlocks after issuing any other new commands. Keyboard jogging in between works until the controller hardlocks. Connection cannot be reestablished with controller over any means. Issue is only present on Ethernet connection. Issue cannot be replicated on USB Serial connection.

I took a video of the exception: https://www.youtube.com/watch?v=cb4VMLmiTxo

Teensy 4.1 hangs if N_AXIS >3

No errors on compile, but as soon as N_AXIS is set above 3, no response from the controller.

Comport opens no error.
No replies from the controller.

Tested with almost all options (Eth/SD/Encoder), still hangs regardless of what is enabled (or not).
Ganged/Auto-square, etc. do not change anything (Auto-square Y works with N_AXIS == 3)

Building with >3 Axes.

In grbl/config.h, line 38, set N_AXIS to 5
#define N_AXIS 5 // Number of axes
and compile. Get numerous errors of the form

D:\Documents\Arduino\libraries\grblHAL_Teensy4\src\T41U5XBB_map.h:26:2: error: #error "Axis configuration is not supported!"
#error "Axis configuration is not supported!"

When N_AXIS is set to 4, the problem does not occur.

This occurs because N_ABC_MOTORS is getting set to 3 when N_AXIS is 5.
I put #warning messages in driver_opts.h and T41U5XBB_map.h and it looks like N_ABC_AXIS is 2 and N_GANGED is 0 so when N_ABC_MOTORS is set in driver_opts.h it should be 2. Yet in T41U5XBB_map.h, N_ABC_MOTORS is 3.
I placed this in T41U5XBB_map.h before the error test around line 24.

#if N_ABC_MOTORS == 3
#warning "N_ABC_MOTORS == 3"
#elif N_ABC_MOTORS == 4
#warning "N_ABC_MOTORS == 4"
#endif

The compiler prints out:

#warning "N_ABC_MOTORS == 3"

Using Arduino 1.8.15 and Teensyduino 1.54

my_machine in both cases (4 and 5 AXIS):

/*
  my_machine.h - configuration for IMXRT1062 processor (on Teensy 4.x board)

  Part of grblHAL

  Copyright (c) 2020 Terje Io

  Grbl is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  Grbl is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with Grbl.  If not, see <http://www.gnu.org/licenses/>.
*/

// BOARD_T40X101 and BOARD_T41U5XBB by Phil Barrett: https://github.com/phil-barrett/grblHAL-teensy-4.x

// NOTE: Only one board may be enabled!
// If none is enabled pin mappings from generic_map.h will be used
//#define BOARD_T40X101
#define BOARD_T41U5XBB
//#define BOARD_T41U5XBB_SS // For a modified T41U5XBB board, allows spindle sync to be enabled.
//#define BOARD_T41BB5X_PRO
//#define BOARD_CNC_BOOSTERPACK
//#define BOARD_MY_MACHINE // Add my_machine_map.h before enabling this!

// Configuration
// Uncomment to enable, for some a value > 1 may be assigned, if so the default value is shown.

/*
              Plugin: | ETHERNET¹ | SDCARD¹ | KEYPAD | EEPROM | N_AXIS |
----------------------|-----------|---------|--------|--------|--------|
BOARD_T40X101         | no        | no      | yes    | yes³   | max 4  |
BOARD_T41U5XBB        | yes       | yes     | yes    | yes³   | max 5  |
BOARD_T41BB5X_PRO     | yes       | yes     | yes    | yes    | max 5  |
BOARD_CNC_BOOSTERPACK | yes²      | yes     | yes    | yes    | max 3  |

¹ Teensy 4.1 only
² External magjack.
³ EEPROM is optional and must be added to the board.

N_AXIS has a default value of 3, edit grbl\config.h to increase.

*/

#define USB_SERIAL_CDC      2 // 1 for Arduino class library and 2 for PJRC C library. Comment out to use UART communication.
//#define USB_SERIAL_WAIT     1 // Wait for USB connection before starting grblHAL.
//#define BLUETOOTH_ENABLE    1 // Set to 1 for HC-05 module. Requires Bluetooth plugin.
//#define SPINDLE_HUANYANG    1 // Set to 1 or 2 for Huanyang VFD spindle. Requires spindle plugin.
//#define QEI_ENABLE          1 // Enable quadrature encoder interfaces. Max value is 1. Requires encoder plugin.
#define ETHERNET_ENABLE     1 // Ethernet streaming. Requires networking plugin.
//#define SDCARD_ENABLE       1 // Run gcode programs from SD card, requires sdcard plugin.
//#define KEYPAD_ENABLE       1 // I2C keypad for jogging etc., requires keypad plugin.
//#define PLASMA_ENABLE       1 // Plasma/THC plugin. To be completed.
//#define MCP3221_ENABLE      1 // Enable analog input via MCP3221 ADC.
//#define PPI_ENABLE          1 // Laser PPI plugin. To be completed.
//#define ODOMETER_ENABLE     1 // Odometer plugin.
//#define OPENPNP_ENABLE      1 // OpenPNP plugin. To be completed.
//#define FANS_ENABLE         1 // Enable fan control via M106/M107. Requires fans plugin.
//#define EEPROM_ENABLE       1 // I2C EEPROM support. Set to 1 for 24LC16(2K), 2 for larger sizes. Requires eeprom plugin.
//#define EEPROM_IS_FRAM      1 // Uncomment when EEPROM is enabled and chip is FRAM, this to remove write delay.
//#define SPINDLE_SYNC_ENABLE 1 // Enable spindle sync support (G33, G76). !! NOTE: Alpha quality - enable only for test or verification.
                                // Currently only available for BOARD_T41BB5X_PRO and BOARD_T41U5XBB_SS.
//#define ESTOP_ENABLE        0 // When enabled only real-time report requests will be executed when the reset pin is asserted.
                                // Note: if left commented out the default setting is determined from COMPATIBILITY_LEVEL.

// If the selected board map supports more than three motors ganging and/or auto-squaring
// of axes can be enabled here.
//#define X_GANGED            1
//#define X_AUTO_SQUARE       1
//#define Y_GANGED            1
//#define Y_AUTO_SQUARE       1
//#define Z_GANGED            1
//#define Z_AUTO_SQUARE       1
// For ganged axes the limit switch input (if available) can be configured to act as a max travel limit switch.
// NOTE: If board map already has max limit inputs defined this configuration will be ignored.
//#define X_GANGED_LIM_MAX    1
//#define Y_GANGED_LIM_MAX    1
//#define Z_GANGED_LIM_MAX    1
//

#if ETHERNET_ENABLE > 0
#define TELNET_ENABLE           1 // Telnet daemon - requires Ethernet streaming enabled.
#define FTP_ENABLE              1 // Ftp daemon - requires SD card enabled.
#define WEBSOCKET_ENABLE        1 // Websocket daemon - requires Ethernet streaming enabled.
#define NETWORK_HOSTNAME        "GRBL"
#define NETWORK_IPMODE          1 // 0 = static, 1 = DHCP, 2 = AutoIP
#define NETWORK_IP              "192.168.5.1"
#define NETWORK_GATEWAY         "192.168.5.1"
#define NETWORK_MASK            "255.255.255.0"
#define NETWORK_TELNET_PORT     23
#define NETWORK_WEBSOCKET_PORT  80
#define NETWORK_HTTP_PORT       80
#endif

Sub-par commenting Grbl-Hal sections of code

I'm somewhat disappointed with the lack of comments the code. Specifically related to the GrblHAL drivers. One of the reasons that I love Grbl, is that the code is very well commented which makes it easy to configure and implement in existing CNC machines.

GrblHAL code should have comments similar to GRBL, but the GRBLHAL components of the code are lacking explanation.
For example, I spent some time last night trying to understand what the encoder switch does in the encoder plugin, but the code is so sparsely commented that I was unable to quickly and easily understand how the encoder plugin and functions within the plugin work.

I decided to post this issue to flag everyone working on GrblHAL to remember to properly comment your code so that we can better understand how to use and apply GrblHAL to our real-world machines. The code should have comments before each function explaining what the function does, as well as comments added to the top of pages explaining what the overall code is supposed to do.

Why I'm disappointed:
I decided to move a CNC to GrblHAL using Phil Barrett's GrblHal Teensy breakout board The machine originally was operating based on https://github.com/bdurbrow/grbl-Mega. The code in the grbl-Mega project has similar features to the driver features in GrblHal, but it is much better commented and therefore much easier to implement in the real-world. It might be better in my case to use older hardware with well commented code, than to use the latest software/hardware (GrblHAL) due to the lack of code comments. I hope that GrblHAL code evolves to the point of being as awesome and easy to use as Grbl itself!

@terjeio Go easy on me. ;)

Thanks!

Properly compile firmware for a dual-stepper-Y machine

Dear all,
I am trying to compile the firmware for a machine using a dual-stepper configuration for moving the Y axis. I am using GRBLHAL2000 board and I would like the auto-square enabled for the Y axis for which I am using two separate steppers (connected to Y and A drivers) and two separate end-stops. I read the documentation, but I am confused (I am also new to GRBL firmware), in particular, I am not sure which files have to be customized. I found that my_machine.h contains a section dedicated to GANGED/AUTO-SQUARE axis and I am wondering if defining #define Y_AUTO_SQUARE 1 is enough or if there are other settings to be done.

Moreover, I am not sure if setting stepper/driver A as the second Y axis is a compile-time setting or not (and in the case where is this setting).

I am sorry if this help request is off-topic or if similar questions have been already answered.

Kind regards.
Stefano

P.S. A complete example of a configuration for a machine with dual-stepper-Y would be very precious for me, is there any example available?

Teensy 4.1 hangs on custom board

Dear all, I need help as I am stuck with teensy4.1 hang issues. This may not be a grblHAL related issue though. I need some favour. My observations / descriptions are as under:

1. I am using my own webUI named grblTouch. I have connected RPi4 with 7 inch display to grblHAL teensy4.1 custom board via a network router with ethernet cables.
2. The setup runs smoothly when I use a particular brand SMPS (wago), but not with other different brands (phoenix, delta, rishabh) with same 24V 5A rating.
3. Now focussing one one non-working setup with rishabh SMPS, it works while I have not connected limit switches. This means it is obviously EMI issues. But it doesn't false trigger hard limit ever. That means is is 24v and 0v lines which enters with emi noise to pcb.
4. Upon attaching scope to 24v and 0v lines at different places in circuit, it shows steady 24v without spikes. After a 24v to 5v buck converter (common ground) in circuit, it shows spikes. 3.3v from the teensy board shows maximum spikes. It ranges from 4.8v to 1.0v. To my surprise, I checked with Wago SMPS again and it shows same level of spikes. But with that smps, the circuit performs well.
   I am now clueless. Can somebody point me to right direction about what to check?
   Sorry for asking hardware (it seems like that) issue here.

Null pointer issue in TCPStream.c

I think there might be a problem with TCPStream.c that breaks ethernet on the IMXRT1062 at the moment. I am pretty sure that the call hal.stream_select(NULL) goes nowhere and so while you can enable ethernet and the device will come up and ping, as soon as you open a telnet session and send a command it immediately locks up the board.

I reverted these calls to the previous selectStream function and it appears to work ok - I can open a telnet session and interact with the device as expected.

If there are updates needed to the iMX driver to align it with the updated stream switching functionality, I can certainly take a crack at a PR if there is an example driver that is known to work. It looks to me like it is just that the stream_select function pointer isn't defined in the driver.

Cheers,

Using native USB host port as HID input for wireless keyboards

Hi @terjeio
I was wondering if I can use native USB host port of Teensy4.1 to connect wireless keyboard dongle and make it work like a pendant. This will save i2c keypad pins which can be used for some other tasks. You can point me how to do that if it is possible.
Regards
Ravi

How to input Motor Fault signal?

Hi @terjeio

Enabling #define MOTOR_FAULT_ENABLE 1 and defining its pin in custom board map doesn't work for me to take Motor Fault input. Is there anything else I am missing? I am using a little older version of grblHAL as I am finding difficulties to compile and run latest code. My startup messages are here for your quick reference:

[VER:1.1f.20220123:]
[OPT:VNMSL+,35,1024,5,0]
[NEWOPT:ENUMS,RT+,ES,TC,SED,ETH,FTP,SD]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:220111]
[DRIVER OPTIONS:USB.2]
[BOARD:BOARD_VALAY]
[AUX IO:0,2,0,0]
[IP:192.168.0.77]
[NETCON:Websocket]
[PLUGIN:WebUI v0.02]
[PLUGIN:SDCARD v1.05]
ok

BTW, I need functionality similar to Estop for Motor Fault. Just the console message should state that the Alarm is caused by motor fault and not by Estop.

Teensy 4.1 hangs at full buffer and trigger of emergency stop

Hi,

thanks for your great work with grblHal.

I am encountering an issue regarding jogging. I am currently trying to implement my own gamepad driver for jogging in cncjs with grblHal on a T41U5XBB board and do send a lot of $J=G91G21X-3.3Y0.0Z0.0F1000.00 jog commands to grblHal. Moreover - due to the unfinished nature of my code or my laziness - I do not check for the Ack from grblHal. Thus, these jog commands stack up until plan and receive buffers are full.

If I trigger with full buffers the emergency stop pin the Teensy is becoming completely unresponsible, only a hard power reset helps.

It may be a stupid question, but is it expected that a full buffer leads to becoming unresponsive? Is it the task of the sender to stop sending in sight of a full buffer? grblHal is my first experience with grbl-based SW and I would have thought that the expected behavior is that grblHal becomes under no circumstances unresponsive.

I can recreate the crash / becoming unresponsive with IOSender, too, if I set the jog values to unreasonable amounts and jog like crazy with the keyboard on all axes:

  <Jog>
    <KeyboardEnable>false</KeyboardEnable>
    <FastFeedrate>3000</FastFeedrate>
    <SlowFeedrate>3000</SlowFeedrate>
    <StepFeedrate>3000</StepFeedrate>
    <FastDistance>300</FastDistance>
    <SlowDistance>300</SlowDistance>
    <StepDistance>300</StepDistance>
  </Jog>

Here are my build settings ($I):

[VER:1.1f.20211010:]
[OPT:VNMZSL,35,1024,3,0]
[NEWOPT:ENUMS,RT+,HOME,ES,EXPR,TC,SED]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:210930]
[DRIVER OPTIONS:USB.2]
[BOARD:T41U5XBB]
[AUX IO:4,3,0,0]

Thank you for your time.

Coolant Flood/Mist pins reversed

Built a T41U5XBB board recently (v2.09), flashed it originally using a pre-built 3 axis, auto squaring binary.

Download the iMXRT1062 driver and built it using the Arduino IDE. When uploaded I noticed that the Flood and Mist board outputs were reversed. I swapped pins 18 and 19 in the T41U5XBB_map.h and my board correctly responds to a M7 command from bCNC now. Might confirm with Phil if my changes are correct.

aggiungere pin alla configurazione

Salve, attualmente ho un finecorsa per l'asse X (-x), uno per l'asse Y (-y) e uno per la Z (-z) che utilizzo normalmente per l'homing. è possibile aggiungere un +X, +Y e +Z da usare solo come hard limit, niente homing?
La mia asse Z, inoltre, è composta da un piano che sale e viene rilevato da un finecorsa induttivo e retrocede per impostare la giusta distanza del mio fuoco laser (co2). Per motivi di sicurezza posso mettere un secondo set di finecorsa (2) per l'asse Z, uno sopra e uno sotto, e attivare, solo su questi, l'hard limit oppure qualcosa che blocca la macchina se attivato? Quello sopra posizionato 3-5mm oltre il sensore induttivo in modo tale da scongiurare un errore di lettura dell'induttivo sotto, anche per evitare che il piano sale fino a sbattere contro la testa laser.
Se è possibile questa configurazione cosa devo cambiare e compilare?

BLTouch Servo Probe

Is it possible to use a BLTouch probe with grblHAL on teensy41?
I have a small sketch using the arduino Servo library which works,
when using the library from inside a plugin, the probe doesnt work.

This seems to be a similar attempt but directly controlling the servo:
grblHAL/core#280
Trying to apply the changes to this repo, noticed for teensy "RC Servo/ESC for spindle" isnt supported.
What would it take to add support for servos?

COOLANT_MIST_PIN changing from pin 24 to any other available pin breaks communication with board after flashing successfully.

I am having a weird issue where in my customized board map, when I change pin 24 to other than COOLANT_MIST_PIN or even disabling COOLANT_MIST_PIN breaks USB as well as Ethernet communication after successfully compiling and flashing to Teensy 4.1. Any clues? Here is my board map file for your reference:

#if N_ABC_MOTORS > 2
#error "Axis configuration is not supported!"
#endif
#if SPINDLE_SYNC_ENABLE
#error "Spindle sync is not supported for T41U5XBB!"
#endif
#define BOARD_NAME "BOARD_VALAY_V7P6"
#define HAS_IOPORTS
#define STEPPERS_ENABLE_PIN (30u)
#define X_STEP_PIN (2u)
#define X_DIRECTION_PIN (3u)
//#define X_ENABLE_PIN (10u)
#define X_LIMIT_PIN (19u)
//#define X_LIMIT_PIN_MAX (17u)
#define Y_STEP_PIN (4u)
#define Y_DIRECTION_PIN (5u)
// #define Y_ENABLE_PIN (40u)
#define Y_LIMIT_PIN (20u)
//#define Y_LIMIT_PIN_MAX (21u)
#define Z_STEP_PIN (6u)
#define Z_DIRECTION_PIN (7u)
// #define Z_ENABLE_PIN (39u)
#define Z_LIMIT_PIN (21u)
//#define Z_LIMIT_PIN_MAX (23u)
// Define ganged axis or A axis step pulse and step direction output pins.
#if N_ABC_MOTORS > 0
#define M3_AVAILABLE
#define M3_STEP_PIN (8u)
#define M3_DIRECTION_PIN (9u)
#define M3_LIMIT_PIN (22u)
//#define M3_ENABLE_PIN (38u)
#endif
// Define ganged axis or B axis step pulse and step direction output pins.
#if N_ABC_MOTORS == 2
#define M4_AVAILABLE
#define M4_STEP_PIN (10u)
#define M4_DIRECTION_PIN (11u)
#define M4_LIMIT_PIN (23u)
//#define M4_ENABLE_PIN (37u)
#endif
// Define spindle enable and spindle direction output pins.
#define SPINDLE_ENABLE_PIN (28u)
#define SPINDLE_DIRECTION_PIN (29u)
#define SPINDLE_PWM_PIN (12u) // NOTE: only pin 12 or pin 13 (LED) can be assigned!
// Define flood and mist coolant enable output pins.
#define COOLANT_FLOOD_PIN (25u)
#define COOLANT_MIST_PIN (24u)
// Define user-control CONTROLs (cycle start, reset, feed hold, door) input pins.
#define RESET_PIN (41u)
#define FEED_HOLD_PIN (40u)
#define CYCLE_START_PIN (39u)
#define SAFETY_DOOR_PIN (14u)
#define ESTOP_PIN (17u)

#if MOTOR_FAULT_ENABLE
#define MOTOR_FAULT_PIN (16u)
#endif

//For LED blink plugin
//#define LED_BUILTIN (13u)
// Define probe switch input pin.
#define PROBE_PIN (18u)
#if QEI_ENABLE
#define QEI_A_PIN (30u) // ST1
#define QEI_B_PIN (34u) // ST2
#define QEI_SELECT_PIN (35u) // ST3
#endif
// Define auxillary input pins
#define AUXINPUT0_PIN (36u) // ST0
#if !QEI_ENABLE
#define AUXINPUT1_PIN (37u) // ST1
#define AUXINPUT2_PIN (38u) // ST2
#define AUXINPUT3_PIN (15u) // ST3
#endif
#define AUXOUTPUT0_PIN (33u) // AUX0 13 is LED pin, 24 is mist pin, 33 is final
#define AUXOUTPUT1_PIN (34u) // AUX1
#define AUXOUTPUT2_PIN (35u) // AUX2
//#define AUXOUTPUT3_PIN (32u) // AUX3
#if KEYPAD_ENABLE
#define KEYPAD_STROBE_PIN (41u) // I2C ST
#endif
//#if EEPROM_ENABLE || KEYPAD_ENABLE
//#if I2C_ENABLE
//#define I2C_PORT 4
//#define I2C_SCL4 (24u) // Not referenced, for info only
//#define I2C_SDA4 (25u) // Not referenced, for info only
//#endif

RC PWM Spindle control

Thank you Terje for the implementation of the RC PWM spindle speed control, it is working well. It does everything needed for a spindle speed controlled by a RC PWM BLD driver. I just notice one thing, when setting the max spindle speed, it is not working, it accepts the input but stays at 1000rpms max. for calculating the pwm signal.

I have run the compile both with Arduino IDE and PlatformIO with MCP3221 Enabled.

I have run the compile both with Arduino IDE and PlatformIO with MCP3221 Enabled.

The following compile time errors occur on lines 129 and 386 in ioports.c

src\ioports.c: In function 'wait_on_input':
src\ioports.c:129:20: error: 'analog_n_in' undeclared (first use in this function)
else if(port < analog_n_in)
^
src\ioports.c:129:20: note: each undeclared identifier is reported only once for each function it appears in
src\ioports.c: In function 'ioports_init':
src\ioports.c:386:34: error: 'analog_n_in' undeclared (first use in this function)
hal.port.num_analog_in = analog_n_in = 1;

I have found a MCP3221 "daughter card" on Phil-Barrett's github.

Originally posted by @sntlewis in #67

UART communication mode not working for current version

Commenting out "#define USB_SERIAL_CDC 2" in my_machine.h to use UART on pins 0, 1 for Teensy4.1 does not work in current version. Seems like the board is just crashing and resetting itself.

Compile errors with latest code.

Trying to publish some updated builds, I am getting some compile errors that seem to be related mainly to the RTC functions. I get these errors even with a completely fresh checkout of the core iMXRT1062 repo.

src\driver.c:2215:16: error: invalid initializer
src\driver.c:2217:13: error: incompatible type for argument 1 of 'rtc_set'
     rtc_set(t);
             ^


src\driver.c: In function 'get_rtc_time':
src\driver.c:2225:20: error: invalid initializer
         time_t t = rtc_get();


src\grbl\nuts_bolts.c: In function 'get_datetime':
src\grbl\nuts_bolts.c:287:22: error: storage size of 'dt' isn't known
     static struct tm dt;
                      ^

src\grbl\nuts_bolts.c:293:27: error: invalid application of 'sizeof' to incomplete type 'struct tm'
     memset(&dt, 0, sizeof(struct tm));
                           ^

"Available driver options can be found here" link is broken for iMXRT1062 Driver

On the page for the iMXRT1062 Driver the link to the available driver options is 404.