and another one to try more problems found, it claims it gets through the calculations now, I’m trying to have it simulate the full calibration after this now.
Upload rejected, Not enough space
just checking (because it’s a mistake I’ve made), you did upload this through the firmware button, not the file upload button?
this is reporting as 1.93m but it is a few dozen bytes larger than prior firmware.
I hope we aren’t actually running up against the limit.
I was able to upload it on my board
Yes I used the firmware button. I think I’ve had enough practice in the last few days.
It got to 99% before it failed
checking, we are just under 2m and the maslow has 3m partitioned for the firmware
I think I’ve had enough practice in the last few days.
I figured you had, but everyone makes mistakes. please check and try again (see if the serial logs report anything)
I presume it doesn’t wipe the existing until it’s loaded the new
Powered it down, restarted the USB connection. This time it loaded. So see how we go.
No good news
Maslow-serial - 2025-10-07T173234.764.log (6.5 KB)
StillBrokenSamePlaceDifferent.txt (14.0 KB)
Ian Abbott wrote:
I presume it doesn’t wipe the existing until it’s loaded the new
apparently there are two partitions, so you can fill one entirely without
touching the old, running copy.
from copilot:
Verified - firmware fits comfortably on the ESP32-S3 controller:
Current Build:
Flash: 2,018,881 bytes / 3,080,192 bytes (65.5%)
RAM: 138,060 bytes / 327,680 bytes (42.1%)
Available Space:
Flash: 1,061,311 bytes free (1+ MB headroom)
RAM: 189,620 bytes free (185 KB headroom)
Board Configuration:
Target: ESP32-S3 with 8MB flash
Partition: max_littlefs.csv (3 MB app partitions)
OTA: Dual partition support maintained
Status: ✓ FITS PERFECTLY
The firmware uses only 65.5% of the 3MB application partition, leaving 34.5%
safety margin. Recent code changes added ~50-100 bytes (negligible). OTA updates
fully supported with both app0 and app1 partitions able to hold the firmware
comfortably.
looks like an error as it’s resizing the array of points…
Perfect! I’ve fixed the heap corruption issue. The problem was that gridSizeX and gridSizeY were being declared without initialization, and if any issue occurred during the calculation, they would contain garbage values. When these uninitialized variables were used in calculateGridPointCount(), it caused heap corruption.
from ai:
The fix:
Initialize variables at declaration: Both gridSizeX and gridSizeY are now initialized to safe defaults (9) immediately when declared
Simplified log messages: Removed the verbose spacing information from log messages to reduce temporary string allocations that could contribute to heap pressure
Guaranteed valid state: Variables are now always in a valid state before being used in any calculations
( I may not respond to your reply tonight, I have to be up in 7 hours)
Thats fine I am working tomorrow morning about 14 hours from now. I will run it now so talk to you tomorrow afternoon (my time). Fantastic the amount of work you have put into these changes.
[MSG:INFO: Measured waypoint 14]
[MSG:INFO: Requesting state change from Calibrating to Calibration Computing]
[MSG:INFO: Succeeded]
[MSG:INFO: Current state: 9]
$/Maslow_tlX=-172.500
$/Maslow_tlY=4015.400
$/Maslow_trX=4530.400
$/Maslow_trY=3973.400
$/Maslow_brX=4552.600
00.19},{bl:3125.15, br:2994.58, tr:2902.04, tl:3212.18},{bl:3225.25, br:3090.77, tr:2803.09, tl:3131.26},{b]
[MSG:INFO: Spoilboard thickness set to 0.000 mm]
[MSG:INFO: Work thickness set to 0.000 mm]
[MSG:INFO: Spoilboard thickness set to 0.000 mm]
[MSG:INFO: Spoilboard thickness set to 0.000 mm]
[MSG:INFO: Work thickness set to 0.000 mm]
[MSG:INFO: Spoilboard thickness set to 0.000 mm]
[MSG:INFO: Work thickness set to 0.000 mm]
assert failed: remove_free_block heap_tlsf.c:206 (next && “next_free field can not be null”)
Backtrace: 0x40379a06:0x3fceb9e0 0x4037ebe1:0x3fceba00 0x40385cd9:0x3fceba20 0x4038517e:0x3fcebb50 0x40385821:0x3fcebb70
ELF file SHA256: b23a65125ab5fb85
Rebooting…
Failed at wavepoint 14.txt (15.7 KB)
1 Like
Just a description of what happened and some of my thoughts.
First time through it did the initial 6 waypoints then started on the 2nd series of way points. Unlike the existing calibration, which does an intermediate rectangle at about half the table size, it went right out to the sides. About halfway along the “top” (Maslow is horizontal) the power pulled out and everything stopped. Fixed, did the dance and restarted.
2nd run, once again initial run 6 waypoints then out to the edge on the next batch of waypoints, got all the way around on that 2nd batch, did it calculations, the tried to suicide over the edge, I hit the power again.
3rd run, initially the same, then failed after the 14th waypoint with
assert failed: remove_free_block heap_tlsf.c:206 (next && “next_free field can not be null”)
never got to the suicide cliff.
4th run Failed after 5th waypoint
[MSG:INFO: Grid dim]
[MSG:INFO: Calibration area: 1.575 m┬▓ (1575123.750 mm┬▓)]
assert failed: multi_heap_free multi_heap_poisoning.c:259 (head != NULL)
Backtrace: 0x40379a06:0x3fcd9330 0x4037ebe1:0x3fcd9350 0x40385cd9:0x3fcd9370 0x403858f1:0x3fcd94a0 0x4037a25d:0x3fcd94c0
ELF file SHA256: b23a65125ab5fb85
Together with the initial difficulty I had loading this version makes me think it must be reserving a block of memory, which is not released between power reboots. The problem seems to move forward with each iteration, with power shut down between each. This site may be helpful.
delete operator - ESP32 heap corruption error when releasing allocated memory - Stack Overflow
I actually had it go backwards. I reported your problem last night and it found a bug, claimed to fix it. I just tested it (at the local hackerspace) and it died with a different type of memory error.
status update, I had access to the local hackerspace maslow today, so did the testing there.
Several issues were identified, but there is still a memory access issue that I’m fighting.
1 Like
latest version to test is here
I suspect that there is an off-by-one error and the last waypoint will not be measured, but I cannot convince the copilot AI about this without a report.
David Lang
Near disaster here
Maslow did initial belts loose run for 1st 6 waypoints as usual, then 6-14 with extremely small steps Approx 12mm each then 15-30 again very small steps between waypoints. I then proceeded down the middle of the table and tried to suicide off the end. just got to power as it tilted. Fortunately, the table is mobile, so I was able to manoeuvre it under the Maslow prior to release tension. Logs attached
ConfigRunSerial20251009T431.txt (6.9 KB)
Maslow-serial - 2025-10-09T043335.853.log (15.7 KB)
Incidentally, it set the Config grid to 100x100mm