I will take a look,
I remember from my other size program based off of Franks stuff (https://github.com/KurtE/imxrt-size)
simply returned -1 from main which caused the build to error out.
I will take a look,
I remember from my other size program based off of Franks stuff (https://github.com/KurtE/imxrt-size)
simply returned -1 from main which caused the build to error out.
This new size program parses the binary .elf file directly, so we're not depending on the specifics of a human readable text format. ELF 32 bit is a very stable binary format.
I tried to keep the main program part as simple as possible so it's easy to edit. The elf parsing code is a bit complicated, but you shouldn't need to dive into that code, as it gives easy function to get the size of any of the linker script's output segments. That's not depending on any symbol values. It's the actual size of the binary segments the compiler generated.
There's also a function you can call to fetch any symbol value, if you know its name. So you could grab the values like "_estack" or "_heap_start" or "_ebss" if you like. Currently it's only used to grab the Teensy model number.
Thanks,
Will play soon, trying to help someone update the RF24 library right now to handle multiple SPI ports.
I submitted a PR for first pass:
I have an RA8876... test sketch that did a picture embed. That compiled fine with PROGMEM defined, but if as I have now, commented that out, it errors out the build.
I did the compute for free stack space using int32_t and return -1 from program if it is <= 0
Note: I printed out the value using %d so it shows the minus number.
Wondering if I should do the same for Free for files and free for malloc as well?
Decided to go ahead and check the other two regions as well and error out.
Also print out message... Feel free to change anything
Havn't used it for years.. do we still support the eeprom-files?
If yes, they should be added.
When there is an error to result in a '-1' exit - the text "teensy_size: " should NOT be printed on the Error line so it gets proper color coding.Originally Posted by KurtE
I submitted a PR for first pass:
I have an RA8876... test sketch that did a picture embed. That compiled fine with PROGMEM defined, but if as I have now, commented that out, it errors out the build.
I did the compute for free stack space using int32_t and return -1 from program if it is <= 0
Note: I printed out the value using %d so it shows the minus number.
Wondering if I should do the same for Free for files and free for malloc as well?
Did PR to have ERRORS get highlighted in console:
Would be better to highlight just the error line - but that is more change with selective prefix.Code:char *prefix = "teensy_size: "; if ((free_flash < 0) || (free_for_local <= 0) || (free_for_malloc < 0)) { retval = -1; prefix = ""; }
> maybe just as well to have hole block stand out
PR updated for only resources in Error to show in console COLOR.
github.com/Defragster/teensy_size/blob/patch-1/teensy_size.c
If you over alloc in an OBVIOUS way - or even barely:
The build breaks in ld.exe before getting to run the teensy_size.exe:
Running IDE 1.8.13 w/TD 1.54 b6 on Win 10 PRO.Code:t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: address 0x2008e340 of C:\Users\Tim\AppData\Local\Temp\arduino_build_104137/BlinkWithoutDelay.ino.elf section `.bss' is not within region `DTCM' t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\Tim\AppData\Local\Temp\arduino_build_104137/BlinkWithoutDelay.ino.elf section `.bss.dma' will not fit in region `RAM' t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: address 0x2008e340 of C:\Users\Tim\AppData\Local\Temp\arduino_build_104137/BlinkWithoutDelay.ino.elf section `.bss' is not within region `DTCM' t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM' overflowed by 60608 bytes collect2.exe: error: ld returned 1 exit status Error compiling for board Teensy 4.1.
I wasn't going to bother testing in IDE - with new computer and getting a dos box to build with gcc and finding make ...
But I did the JAR's and added the platform.txt and put the EXE in to tools ...
HERE is my built copy of teensy_size.exe nd also the blink sketch :Started with BlinkWithoutDelay.ino.Code:teensy_size.zip
Added some allocs:
When I abuse the buf's to:Code:Memory Usage on Teensy 4.1: FLASH: code:35564, data:5632, headers:7212 free for files:8078056 RAM1: code:32768, variables:25408 free for local variables:466112 RAM2: variables:24768 free for malloc/new:499520 EXTRAM: variables:8388608
Code:EXTMEM char buf[8 * 1024 * 1024]; DMAMEM char bufX[495 * 1024]; char bufY[495 * 1024];
Above says I have 832 bytes free in RAM2, adding 832 shows ZERO free.Code:Memory Usage on Teensy 4.1: FLASH: code:35564, data:5632, headers:7212 free for files:8078056 RAM1: code:32768, variables:521024 free for local variables:-29504 RAM2: variables:523456 free for malloc/new:832 EXTRAM: variables:8388608 Error program exceeds memory space exit status -1 Error compiling for board Teensy 4.1.
This result when going to :: DMAMEM char bufX[495 * 1024 + 833];
Code:t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\Tim\AppData\Local\Temp\arduino_build_104137/BlinkWithoutDelay.ino.elf section `.bss.dma' will not fit in region `RAM' t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM' overflowed by 32 bytes collect2.exe: error: ld returned 1 exit status Error compiling for board Teensy 4.1.
Following p#85 shown above.
It looks like RAM calc goes in 4K chunks? Not a code multiply but from ?? :: "data = elf_section_size(".data");"
Using this for RAM is too much - like anything higher than 464 :: char bufY[464 * 1024];
But reducing that by 1K to :: char bufY[463 * 1024];Code:Memory Usage on Teensy 4.1: FLASH: code:35564, data:5632, headers:7212 free for files:8078056 RAM1: code:32768, variables:492352 free for local variables:-832 RAM2: variables:523456 free for malloc/new:832 EXTRAM: variables:8388608 Error program exceeds memory space
Code:Memory Usage on Teensy 4.1: FLASH: code:35564, data:5632, headers:7212 free for files:8078056 RAM1: code:32768, variables:488256 free for local variables:3264 RAM2: variables:523456 free for malloc/new:832 EXTRAM: variables:8388608 "T:\\arduino-1.8.13_t54\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_104137/BlinkWithoutDelay.ino.elf" Sketch uses 40464 bytes (0%) of program storage space. Maximum is 8126464 bytes. Global variables use 520016 bytes (99%) of dynamic memory, leaving 4272 bytes for local variables. Maximum is 524288 bytes. Low memory available, stability problems may occur.
@defragster - Looks great. Interesting with Low memory availability messages, I assume they most use a percentage... As 4K free on an LC would be 50%
I see the changes were pulled in
Just put a note on Frank_B's PR Print Hardfaults #535 - that would be good to have in Beta 7 release so a thread could be started to discuss and put it to use on T_4.x's.
@KurtE - 4K bump was in the error detection as I saw it? Not the low memory. Low memory came in that code at 463 * 1024 , when 3264 bytes left is indicated by teensy_size.exe. But at 464 * 1024 it claimed a 832 byte deficit? - the same -832 up to char bufY[467 * 1024];
Also note when testing the linker ended up reporting the 'out of memory' error and failing as the 'referred to' .ELF was created { but is NOT present } and the teensy_size.exe was then not called
Though putting this line in boards.txt caused the Linker to show its math before it reported the error which in that case was more useful than the raw linker error text:
The next step in 1K at : char bufY[496 * 1024];Code:teensy41.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_t41.ld"
Code:Memory region Used Size Region Size %age Used ITCM: 31772 B 512 KB 6.06% DTCM: 525120 B 512 KB 100.16% RAM: 523456 B 512 KB 99.84% FLASH: 48416 B 7936 KB 0.60% t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: address 0x20080340 of C:\Users\Tim\AppData\Local\Temp\arduino_build_104137/BlinkWithoutDelay.ino.elf section `.bss' is not within region `DTCM' t:/arduino-1.8.13_t54/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: address 0x20080340 of C:\Users\Tim\AppData\Local\Temp\arduino_build_104137/BlinkWithoutDelay.ino.elf section `.bss' is not within region `DTCM' collect2.exe: error: ld returned 1 exit status ERAM: 8 MB 16 MB 50.00% Error compiling for board Teensy 4.1.
@all : new images of the updated T_4.1 is online :: pjrc.com/store/teensy41.html#pins
What is the best way to update? so far I have uninstalled arduino and deleted all folders and reinstalled completely. Is there a less intrusive method?
Note: this is beta 6 thread and Beta 7 is current.
Generally TeensyInstaller can just be run over any old instance.
The IDE should never need to be reinstalled.
Worst case is orphaned files ( rare ) get left behind with changes. Any files of the same names will be overwritten
To be certain on some updates: the "..."\hardware\teensy\avr\ folder could be deleted before running a new TeensyInstaller - this would prevent orphaned source files from prior installs from confusing anything after the new install.
That is the best way. At least where "best" means certainty to always give the correct result.
On Windows, if you just run the EXE installer, it will automatically delete the older copy (assuming you always use the default location) so you don't need to manually delete any files. Just running Arduino's EXE installer again is enough. On Linux & Macintosh (or on Windows using the non-admin ZIP), best to delete the old copy and then extract a fresh copy from the downloaded .tar.xz or .zip file.
Generally the installers are meant to be able to install a new version "on top of" any older version. With these betas, I try to mention any known cases where that won't work. The rename of SdFat's folder from 1.54-beta4 to 1.54-beta5 is the only one I know has an issue. But I try to avoid those sorts of things so the "fastest" way of just installing into a copy of Arduino which contains an earlier Teensyduino will usually just work.Is there a less intrusive method?
Reverting to an older version should always be done the "best" way. The installers don't know how to delete files in the non-core library, so older versions can't wipe away stuff newer versions add in the many other libraries. Each installer checks if a newer version is already present and will not attempt a downgrade. But that check doesn't take the betas into account, so 1.54-beta1, 1.54-beta4, 1.54-beta7 are all just considered to be 1.54. If you want to go back to an earlier beta or even 1.53, extract Arduino again so you have a fresh copy for the older installer.
Posting Permissions
