Error while writing to Teensy 4x

[david-res]

I get the following error when trying to upload a hex to a Teensy MM.

Seems this happens due to my sketch being too big? TeensyLoader can flash it, it just takes a while to erase.
Now, if I let it sit for 30-60 Seconds after that error and then click upload again, it will try to upload, but will present the same error after a while.

Here is the build output of the sketch:
teensy_size: Memory Usage on Teensy MicroMod: teensy_size: FLASH: code:5537116, data:80252, headers:8484 free for files:10889220 teensy_size: RAM1: variables:131520, code:308984, padding:18696 free for local variables:65088 teensy_size: RAM2: variables:336000 free for malloc/new:188288

I know this is due to the amount of flash memory used.
What is the timeout for the erase of the Teensy?

[Koromix]

Mmmh, I don't have a Teensy MicroMod so I can't test anything...

Still, I've changed the code, maybe it works.
Here is a new build: https://koromix.dev/files/tytools/

Can you report if it works?

If it does not, can you copy paste everything under View > Application Log > Full Log?

[david-res]

Thanks for the fast patch!

Unfortunately it doesn't work..

`Add serial device '292b4088347d6' on iface 1

• USB VID/PID = 16c0:04d5, USB location = usb-20-3-3-1-4
• USB manufacturer = Teensyduino, product = Teensy MTP Disk, S/N = 8485220
  Identified 'Teensy MicroMod' with bcdDevice value 0x281
  [upload@8485220-Teensy] Uploading to board '8485220-Teensy' (Teensy MicroMod)
  [upload@8485220-Teensy] Triggering board reboot
  Remove device '292b4088347d6'
  Add HID device '292b730e726ca' on iface 0
• USB VID/PID = 16c0:0478, USB location = usb-20-3-3-1-4
• USB manufacturer = (none), product = (none), S/N = 000CF28A
• HID usage page = 0xff9c, HID usage = 0x26
  Identified 'Teensy MicroMod' with usage value 0x26
  [upload@8485220-Teensy] Firmware: Oakhill_and_Resnik_Performance_Display_v1.3.1.hex
  [upload@8485220-Teensy] Flash usage: 5494 kiB (34.1%)
  [upload@8485220-Teensy] I/O error while writing to 'IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS08@14300000/USB2.0 Hub @14300000/AppleUSB20Hub14300000/AppleUSB20HubPort@14330000/USB2137B@14330000/AppleUSB20Hub@14330000/AppleUSB20HubPort@14331000/USB2.1 Hub@14331000/AppleUSB20Hub@14331000/AppleUSB20HubPort@14331400/IOUSBHostDevice@14331400/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice'
  `

Here is the log.

From playing around with luni's loader in the past, we found that the issue usually is the timeout while it erases the flash before wiring the hex

[david-res]

Hi @Koromix! Have you had time to take a look at the log?

When using luni’s TeensyShap lib, we found that we needed to allow the tool to try write around 250 times with 500ms delays between each attempt to allow a full flash erase without causing any issues

[david-res]

I think if you increase the number of attempts here to 250
r = halfkay_send(iface->port, halfkay_version, block_size, address, buf, buf_len, 250);

And increase the timeout here to 500 hs_delay(addr ? 20 : 500);
might fix this issue, and would allow enough time for the full flash sector to be erased.

[Koromix]

Actually, the delay code has been kind of broken for a while for Teensy 4.x+, because the start address is not 0 on these boards. So the addr ? 20 : 100 did not even work :)

I've pushed a commit that should fix the issue although I don't even have a Teensy with me right now (not at home), so it's untested. I'll improve this more when I get my hand on a Teensy.

Meanwhile, there is a new build at https://koromix.dev/files/tytools/ (untested)

[david-res]

Still seeing the same issue unfortunately, but takes a bit more time for the error to come up now. So its down to timing/retries.

This is how we did it using TeensySharp and it's been working quite well with no hiccups so far.

[mlaboss-rsb]

I am encountering what appears to be the same problem with uploading to a Teensy MicroMod using tycmd. The error message is:

upload@8478780-Teensy I/O error while writing to '\.\HID#VID_16C0&PID_0478#6&2975C0&0&0000#{41de55b2-f16f-11cf-88cb-001111000030}'

Is it possible to get a Windows x64 build with the latest changes to see if they resolve the issue?