Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enabling ethernet causes periodic stalls. #6

Closed
phil-barrett opened this issue Jul 11, 2021 · 8 comments
Closed

Enabling ethernet causes periodic stalls. #6

phil-barrett opened this issue Jul 11, 2021 · 8 comments

Comments

@phil-barrett
Copy link

phil-barrett commented Jul 11, 2021

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]

@terjeio
Copy link
Contributor

terjeio commented Jul 11, 2021

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.

@phil-barrett
Copy link
Author

phil-barrett commented Jul 11, 2021

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...).

@phil-barrett
Copy link
Author

phil-barrett commented Jul 11, 2021

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.

@terjeio
Copy link
Contributor

terjeio commented Jul 11, 2021

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...

@phil-barrett
Copy link
Author

phil-barrett commented Jul 11, 2021

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.

@terjeio
Copy link
Contributor

terjeio commented Jul 11, 2021

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.

@phil-barrett
Copy link
Author

Glad to have a good resolution to this.

@phil-barrett
Copy link
Author

phil-barrett commented Jul 11, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants