'Transfer aborted' message when trying to upload macro files to SD

[axg20202]

I'm running the latest build of grblhal (7 Jan), and current Iosender release. I can't seem to upload files to SD. Existing files are listed. 'Uploading' message is displayed for a few seconds, then 'Transfer aborted'. I have uploaded files to SD before, so not sure what the issue is here. Any ideas?

[terjeio]

Works for me: iMXRT1062 driver - both via YModem and FTP (FTP is used when enabled and connection is up).
Which driver/board?

[axg20202]

iMXRT1062 Teensy breakout board. I wonder if wiping the SD might help. FAT32 yes?

[terjeio]

Odd that it worked before - is the board networked and FTP enabled or are you uploading over USB?
My card is a cheap 2GB HC 10 marked of some asian brand - 888 or ggg?. FAT32 formatted.

[axg20202]

Just using usb. i can remove the sd and copy files to it. they show up in iosender. Its just transfers from the PC that no longer work.

[terjeio]

Anything changed in the setup? Different USB cable?
If you upload a larger file does it fail immediately or does the status line show any bytes beeing transferred before it fails?

[axg20202]

i just tried to upload a gcode file, same error. usb cable is the same.

[axg20202]

Any other ideas on this? Logan suggested there could be an SD setting relating to FTP vs USB uploading, but I can't locate such a setting.

[terjeio]

It is either CRC transmit errors or file create/write errors. The controller only NAKs on failure so impossible for the sender to know the reason. If the Transferred X of Y bytes... status message does appear, even briefly, the file was created successfully...
If you are compiling yourself adding a few debug messages could reveal what the issue is. If I direct you are you able to do that?

[terjeio]

could be an SD setting relating to FTP vs USB

Oops, this could be a clue. If you are running an older version of the controller firmware it may incorrectly report FTP as started even when not. The sender selects the protocol based on "FTP" beeing present in the NEWOPT line in the $I report or not:

[axg20202]

OK, thanks. I don't think that's the issue then.
[NEWOPT:ENUMS,RT+,HOME,ES,REBOOT,EXPR,ATC,SED,SD,YM]

I would certainly be willing to compile myself if that could help. Very much appreciate your help.

[phil-barrett]

In the builder, you need to add networking to get FTP. Does that mean that you can't use (er, upload to) SD without networking? I assume there is no FTP via USB path...

[EDIT] Strike that. Upload with YModem work fine via USB.

[terjeio]

Try this version, replaces ymodem.c in the sdcard folder.
I had to copy messages to a buffer and write that out on transfer ending since the comms channel is claimed by the ymoden protocol during transfer.

ymodem.zip

[axg20202]

Thanks. Before I try this, I made a few discoveries trying lots of different Web builder settings. The issue is with the current web builder. If I select any additional plugins (odomoter, lightburn etc) alone or in combination, SD card file transfer over USB fails. Works fine if none are selected. I usually select lightburn ppi, clusters, and odometer. The problem is there is still another issue with the current web builder that prevents proper rapidchange atc macro functions (I get a tool out of range error when trying to load a tool) so for now I'm stuck with a build from December that works apart from SD transfers.

[axg20202]

I think I will try a new manual compile and see if that resolves my issues. I've generally had good luck with the Web builder but have been having a few issues with it since the last few updates.

[terjeio]

The culprit is the Lightburn clusters plugin, it buffers input and modifies it before returning it for processing. The YModem plugin wants the raw input for itself so the Lightburn plugin cannot be in the loop messing with the data.
The solution to this is to let the YModem plugin take over the input stream at the raw interrupt level. I have it running now, and I guess I'll commit the change tomorrow. I'll leave the Web Builder issues till tomorrow as well.

[axg20202]

Thanks for working out the issue. However, I've discovered that the tool out of range error with the latest build still occurs after a manual compile. Must be unrelated to webbuilder. Would you prefer I open a new issue thread?

[terjeio]

Fix committed for grblHAL YModem issue.

Would you prefer I open a new issue thread?

Yes, since this is also a grblHAL issue.

[axg20202]

Thanks for your help. I've posted the issue in the grblhal git.