Teensyduino 1.54 Beta #6

KurtE · Feb 21, 2021

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.

PaulStoffregen · Feb 21, 2021

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.

KurtE · Feb 21, 2021

Thanks,

Will play soon, trying to help someone update the RF24 library right now to handle multiple SPI ports.

KurtE · Feb 21, 2021

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?

KurtE · Feb 21, 2021

Decided to go ahead and check the other two regions as well and error out.

Also print out message... Feel free to change anything

Frank B · Feb 21, 2021

Havn't used it for years.. do we still support the eeprom-files?
If yes, they should be added.

defragster · Feb 21, 2021

KurtE said:
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

View attachment 23790

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?

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.

defragster · Feb 21, 2021

Did PR to have ERRORS get highlighted in console:

Code:

		char *prefix = "teensy_size: ";
		if ((free_flash < 0) || (free_for_local <= 0) || (free_for_malloc < 0)) {
			retval = -1;
			prefix = "";
		}

Would be better to highlight just the error line - but that is more change with selective prefix.
> maybe just as well to have hole block stand out

defragster · Feb 21, 2021

PR updated for only resources in Error to show in console COLOR.

github.com/Defragster/teensy_size/blob/patch-1/teensy_size.c

defragster · Feb 22, 2021

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:

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.

Running IDE 1.8.13 w/TD 1.54 b6 on Win 10 PRO.

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 :

Code:

[ATTACH]23803._xfImport[/ATTACH]

Started with BlinkWithoutDelay.ino.

Added some allocs:

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

When I abuse the buf's to:

Code:

EXTMEM char buf[8 * 1024 * 1024];
DMAMEM char bufX[495 * 1024];
char bufY[495 * 1024];

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.

Above says I have 832 bytes free in RAM2, adding 832 shows ZERO free.
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.

defragster · Feb 22, 2021

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];

Code:

Memory Usage on Teensy 4.1:
  FLASH: code:35564, data:5632, headers:7212   free for files:8078056
   [COLOR="#FF0000"]RAM1: code:32768, variables:492352   free for local variables:[B]-832[/B][/COLOR]
   RAM2: variables:523456  free for malloc/new:832
 EXTRAM: variables:8388608
[COLOR="#FF0000"]Error program exceeds memory space[/COLOR]

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:488256   free for local variables:[B]3264[/B]
   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.
[COLOR="#FF0000"]Low memory available, stability problems may occur.[/COLOR]

KurtE · Feb 22, 2021

@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

defragster · Feb 22, 2021

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:

Code:

teensy41.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_t41.ld"

The next step in 1K at : char bufY[496 * 1024];

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.

defragster · Feb 22, 2021

@all : new images of the updated T_4.1 is online :: pjrc.com/store/teensy41.html#pins

Fluxanode · Mar 12, 2021

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?

defragster · Mar 12, 2021

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.

PaulStoffregen · Mar 12, 2021

Fluxanode said:
so far I have uninstalled arduino and deleted all folders and reinstalled completely.

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.

Is there a less intrusive method?

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.

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.

Teensyduino 1.54 Beta #6

KurtE

Senior Member+

PaulStoffregen

Well-known member

KurtE

Senior Member+

KurtE

Senior Member+

Attachments

KurtE

Senior Member+

Frank B

Senior Member

defragster

Senior Member+

defragster

Senior Member+

defragster

Senior Member+

defragster

Senior Member+

defragster

Senior Member+

KurtE

Senior Member+

defragster

Senior Member+

defragster

Senior Member+

Fluxanode

Well-known member

defragster

Senior Member+

PaulStoffregen

Well-known member