[GH-ISSUE #399] cannot move location counter backwards #185

New issue

Open

opened 2026-05-06 13:16:04 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-06 13:16:04 +02:00

Owner

Originally created by @romain1235 on GitHub (Apr 13, 2026).
Original GitHub issue: https://github.com/UpsilonNumworks/Upsilon/issues/399

Sometimes, after modifying the upsilon code, I get an error when I compile: cannot move location counter backwards (from 20038070 to 20038000). Every time I've had this error, I've shrunk the Python heap, but I was wondering why it appeared and if there was a way to resolve it without shrinking the Python heap.

Originally created by @romain1235 on GitHub (Apr 13, 2026). Original GitHub issue: https://github.com/UpsilonNumworks/Upsilon/issues/399 Sometimes, after modifying the upsilon code, I get an error when I compile: `cannot move location counter backwards (from 20038070 to 20038000)`. Every time I've had this error, I've shrunk the Python heap, but I was wondering why it appeared and if there was a way to resolve it without shrinking the Python heap.

BreizhHardware commented

2026-05-06 13:16:05 +02:00

Author

Owner

@Yaya-Cout commented on GitHub (Apr 13, 2026):

This error means the calculator doesn't have enough RAM. Everything is statically allocated (i.e. no malloc/free), so there's no issue with the RAM being maxed out
As unused RAM is wasted RAM, almost everything is allocated. There are 3 big buffers you can adjust : Python heap (in apps/code/app.h at line 78), RAM filesystem (ion/include/ion/internal_storage.h line 28) and Poincare pool (poincare/include/poincare/tree_pool.h line 54). Poincare is the math engine.

If there's available memory (I think we have around 230 bytes left currently after the MicroPython upgrade), we increase the size off these buffers. If there's not enough memory, we can reduce their size (if the code can't be optimized to reduce memory usage).

@Yaya-Cout commented on GitHub (Apr 13, 2026): This error means the calculator doesn't have enough RAM. Everything is statically allocated (i.e. no `malloc`/`free`), so there's no issue with the RAM being maxed out As unused RAM is wasted RAM, almost everything is allocated. There are 3 big buffers you can adjust : Python heap (in `apps/code/app.h` at line 78), RAM filesystem (`ion/include/ion/internal_storage.h` line 28) and Poincare pool (`poincare/include/poincare/tree_pool.h` line 54). Poincare is the math engine. If there's available memory (I think we have around 230 bytes left currently after the MicroPython upgrade), we increase the size off these buffers. If there's not enough memory, we can reduce their size (if the code can't be optimized to reduce memory usage).

BreizhHardware commented

2026-05-06 13:16:05 +02:00

Author

Owner

@romain1235 commented on GitHub (May 2, 2026):

there is also the stack, no?

@romain1235 commented on GitHub (May 2, 2026): there is also the stack, no?

BreizhHardware commented

2026-05-06 13:16:05 +02:00

Author

Owner

@Yaya-Cout commented on GitHub (May 2, 2026):

The stack is also manually allocated, at the end of the RAM: https://github.com/UpsilonNumworks/Upsilon/blob/upsilon-dev/ion/src/device/bootloader/bootloader_common.ld#L133
It's 32K when built as a slot (In flasher mode, it's different, so it's not specified in the main linkerscript): https://github.com/UpsilonNumworks/Upsilon/blob/upsilon-dev/ion/src/device/bootloader/bootloader.A.ld

The stack can cause issues when it overflows, because contrary to most operating systems on computer, we don't have any checks (I think there's a function to tell if the stack already overflowed, but it's almost never used). You can try to reduce it if you want to save memory, but this may cause issues with Poincare (the math engine) and some external apps. Reducing the stack size won't be accepted in Upsilon unless there's a strong reason to do so (due to the amount of potential issues).

When I tried to do an initial Numcraft port for Upsilon, one of my issues was the stack. On Epsilon, I think they have a bit more of unallocated memory, so stack overflows are less visible.

@Yaya-Cout commented on GitHub (May 2, 2026): The stack is also manually allocated, at the end of the RAM: https://github.com/UpsilonNumworks/Upsilon/blob/upsilon-dev/ion/src/device/bootloader/bootloader_common.ld#L133 It's 32K when built as a slot (In flasher mode, it's different, so it's not specified in the main linkerscript): https://github.com/UpsilonNumworks/Upsilon/blob/upsilon-dev/ion/src/device/bootloader/bootloader.A.ld The stack can cause issues when it overflows, because contrary to most operating systems on computer, we don't have any checks (I think there's a function to tell if the stack already overflowed, but it's almost never used). You can try to reduce it if you want to save memory, but this may cause issues with Poincare (the math engine) and some external apps. Reducing the stack size won't be accepted in Upsilon unless there's a strong reason to do so (due to the amount of potential issues). When I tried to do an initial Numcraft port for Upsilon, one of my issues was the stack. On Epsilon, I think they have a bit more of unallocated memory, so stack overflows are less visible.