grblHAL / iMXRT1062

grblHAL driver for NXP iMXRT1062 (Teensy 4.x)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Enabling ethernet causes periodic stalls.

phil-barrett opened this issue · comments

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]

This does not happen for me when testing with the Pro board. Last time this surfaced I traced it down to the new rather large constant array of settings desrciptors, commenting out a random one fixed it. To solve it then I a decorated a number of constant arrays with Arduino PROGMEM symbol. Can you try by commenting out or temporarily deleting a bunch of settings descriptors to see if a large constant array still may cause it?

The array starts here:

https://github.com/grblHAL/core/blob/222ba55724741b1ab3b699f3ae4953cc90bc30f5/settings.c#L361

I have no idea what the reason for the failure was last time it surfaced, some peculiarity of the Arduiono/Teensy build system?
No other drivers exhibits this behaviour, and non-Arduino drivers replaces the PROGMEM symbol with an empty string too boot.

I am compiling with Arduino 1.8.13 and Teensy 1.53.

I commented out the Group_Spindle_ClosedLoop settings (5 of them). That "fixed" it. Do you have a suggested array to move into PROGMEM?

Building with the same - Arduino 1.8.13 and Teensyduino 1.53. Teensyduino 1.54 has been in beta for about 5 months and will get released soon so when they declare it stable, I'll give it a try.

I did find a similar sounding issue on the PJRC forum but like a lot of those threads it wandered off endlessly to nothing obvious. There was a suspicion of some sort of timer problem but nothing definitive - mostly "voodoo" fixes (kind of like this one...).

Found the thread here.

[edit] skip to the last couple of pages, it seems to be resolved but, honestly, I don't understand what they did.

Can you change startup.c according to this comment as a first step?

If that does not help...:

I commented out the Group_Spindle_ClosedLoop settings (5 of them). That "fixed" it.

If you comment out some other settings instead does that fix it too?

Do you have a suggested array to move into PROGMEM?

Change line 170 in system.c to
PROGMEM static const sys_command_t sys_commands[] = {

There are two small const arrays in nuts_bolts.h that could be decorated with PROGMEM, and some inside gc_execute_block() in gcode.c as well.

Since it the issue shows up when enabling ethernet then perhaps the const arrays in WsStream.c is the trigger? And there is one in multipartparser.c and one in base64.c...

There was a suspicion of some sort of timer problem but nothing definitive - mostly "voodoo" fixes

It is a very odd issue, strange that I do not see it anymore...

OK, changed startup.c. Built with settings.c reverted to the distribution. It fixes the problem. Not sure whether I should add quotes around fixes. I will look into whether teensyduino 1.54 contains this change.

Great, then it has an explanation.

I will look into whether teensyduino 1.54 contains this change.

Paul commented later in the thread that it does.

I have added PROGMEM to some of the const arrays not having it, it frees up a bit of RAM... RAM is faster so I don't add it to all.

Glad to have a good resolution to this.

Final note. Upgrading to Teensyduino 1.54 seems to have fixed the problem. I recommend that everyone building the iMXRT1062 version of grblHAL upgrade to 1.54 now.