Teensyduino 1.54 Beta #1

[defragster]

tidbit ... processor state ... you know how cell phone near speakers makes them chatter?

So this T_4.1 sitting here in fail state - my wife and I hear this odd noise through speakers mild cyclic chatter/squeal. Fifth and final thing to resolve was turn off the non-blinking Teensy - though it was running SdInfo in a no run state IIRC.

Not sure if that might indicate anything unusual/specific about processor state.

[PaulStoffregen]

I'm pretty sure this will be the official fix.

https://github.com/PaulStoffregen/co...07b79b34ecfc39

Any chance you could edit your copy of startup.c to delete the naked attribute, and then retry the SdFat info?

[defragster]

I'm pretty sure this will be the official fix.

https://github.com/PaulStoffregen/co...07b79b34ecfc39

Any chance you could edit your copy of startup.c to delete the naked attribute, and then retry the SdFat info?

Yes, in about 40 minutes ...

[KurtE]

Good morning Paul,

I tried blink with T4.1 and as well my camera sketch run from sublimetext build and both compiled and programmed two differnt T4.1s

[defragster]

td1.54b1 - reinstall - edits overwrite - default build for T_4.1 new from pack yesterday::
> sdInfo worked once? then failed, Blink failed.

Made edits startups.c : no naked @46, no NOPS @108:
> 4X blink edit and upload
> SdInfo, SdFormatter, SdInfo, SdFormatter, SdInfo
> 4X blinkWithoutDelay edit and upload

All compiles>Uploads restart to running.

<edit>: repeating SAME above on T_4.0 : no problems
> 4X blink edit and upload
> SdInfo, SdFormatter, SdInfo, SdFormatter, SdInfo
> 4X blinkWithoutDelay edit and upload

[defragster]

Another T_4.1 sketch edited/written and tested to run with repeat compile/upload fine with p#30/#27 "official fix".

Uses 8MB of PSRAM for analog time and data storage:
Sketch : Using-PSRAM-Buffer-for-saving-arrays-before-serial-printing
Going to go edit to use 15MB ... <edit> : That worked as expected

BTW: That cyclic Speaker tone happens with Teensy running properly? Not sure why I'm just now hearing it? Not sure I moved/changed anything ... it is sort of subtle low volume.

[mjs513]

Been uploading and reuploading graphicstest9488 on a T4.1 with 8mb PSRAM with upload or compile issues with the change in post #27. Same results with Demosauce. Both times used SPI1 for the test.

Tried BLINK several times as well with no issues.

Also tried my OpenGL 3d model sketch with a ILI9488 on SPI - loading and reloading - no issues on compile or upload and runs fine. Using Frank's flexraminfo dump:

ILI9488_t3::begin - End

OpenGL Test!

FLASH: 112448  1.38% of 7936kB (8014016 Bytes free) FLASHMEM, PROGMEM
ITCM:   70680  0.00% of   96kB (  27624 Bytes free) (RAM1) FASTRUN
OCRAM:
   524288 Bytes (512 kB)
-   12384 Bytes (12 kB) DMAMEM
-   80040 Bytes (78 kB) Heap
   431864 Bytes heap free (421 kB), 92424 Bytes OCRAM in use (90 kB).
DTCM:
   425984 Bytes (416 kB)
-  168640 Bytes (164 kB) global variables
-    1324 Bytes (1 kB) max. stack so far
=========

   256020 Bytes free (250 kB), 169964 Bytes in use (165 kB).

Ran 2 of the w25n01g flash chip examples as well with no issues. Same process - at least 4x loads.

[KurtE]

I have continued to play with the update and so far I think this takes care of it...

Note: Maybe for next (after this fix) wish we had something like this in the imxrt1062_t41.ld file:

	_heap_start = ADDR(.bss.dma) + SIZEOF(.bss.dma);
	_heap_end = ORIGIN(RAM) + LENGTH(RAM);

	_extram_end = ADDR(.bss.extram) + SIZEOF(.bss.extram);

I verified with the command line:

C:\Users\kurte\AppData\Local\Temp\arduino_build_CameraDisplay_ili9341_t3n.ino>\arduino-1.8.13\hardware\tools\arm\bin\arm-none-eabi-gcc-nm -n *.elf > foo

And my test sketch had the line: uint16_t ext_pixel[320*240] EXTMEM;

And the above command did give me the data:

70000000 B ext_pixel
70025800 B _extram_end

So if we then can add in a heap allocater for this area we can know where the sketch allocations ended...
Awhile ago we were playing with a simple allocate only function, that at the time either started at the end of EXTMEM and worked back toward the start. Or with this we could start at this memory location and work up till we get up to the end of this memory.

But again not expecting any of this is this upcoming build.

[luni]

Would it be possible to update Bounce2 to the current version? The one packed with Teensyduino is quite outdated and misses some useful functions.

[luni]

Here a PR for the EEPROM library which implements a check for 'non usable' types and specializes the template to enable String storage https://github.com/PaulStoffregen/EEPROM/pull/5 See also here: https://forum.pjrc.com/threads/62533...l=1#post250005

[defragster]

I have continued to play with the update and so far I think this takes care of it...

Note: Maybe for next (after this fix) wish we had something like this in the imxrt1062_t41.ld file:

	_heap_start = ADDR(.bss.dma) + SIZEOF(.bss.dma);
	_heap_end = ORIGIN(RAM) + LENGTH(RAM);

	_extram_end = ADDR(.bss.extram) + SIZEOF(.bss.extram);

I verified with the command line:

C:\Users\kurte\AppData\Local\Temp\arduino_build_CameraDisplay_ili9341_t3n.ino>\arduino-1.8.13\hardware\tools\arm\bin\arm-none-eabi-gcc-nm -n *.elf > foo

And my test sketch had the line: uint16_t ext_pixel[320*240] EXTMEM;

And the above command did give me the data:

70000000 B ext_pixel
70025800 B _extram_end

So if we then can add in a heap allocater for this area we can know where the sketch allocations ended...
Awhile ago we were playing with a simple allocate only function, that at the time either started at the end of EXTMEM and worked back toward the start. Or with this we could start at this memory location and work up till we get up to the end of this memory.

But again not expecting any of this is this upcoming build.

Thanks for the reminder @KurtE - my td1.53 still has the _t41.ld edit in for this 9/15 post/edit/sketch

That was when I tested against your malloc(EXTRAM) code.

BTW: There is the new sm_malloc library too ... Tested to work :: malloc-free-for-EXTMEM-and-DTCM

It or anything like it would need extent of pre-alloc EXTMEM to work safely.

[PaulStoffregen]

Note: Maybe for next (after this fix) wish we had something like this in the imxrt1062_t41.ld file:

Added.
https://github.com/PaulStoffregen/co...2d3815fb2fbb59

Would it be possible to update Bounce2 to the current version?

Updated Bounce2.

Here a PR for the EEPROM library which implements a check for 'non usable' types and specializes the template to enable String storage

Thanks! Merged.

[defragster]

And I see this went in so a common base for other mem alloc can get tested:

	_extram_start = ADDR(.bss.extram);
	_extram_end = ADDR(.bss.extram) + SIZEOF(.bss.extram);

In conjunction with :: external_psram_size

[KurtE]

Thanks Paul,

Wondering about comments in startup.c

		// TODO: zero uninitialized EXTMEM variables
		// TODO: copy from flash to initialize EXTMEM variables
		// TODO: set up for malloc_extmem()

Do you still see this has something that you would like to get done? I for sure would like to get some heap code in, but wondering if you still wanted the initialized... Obviously interesting question on what it should do if it does not find memory...

Also wonder if it also would make sense for initialized DMAMEM variables? Obviously not for Beta2...

[PaulStoffregen]

Yes, so much to do. But right now I'm packaging up 1.54-beta2, so we can have a much better starting point.

I considered bringing the static malloc stuff into the core library, and will probably do so this weekend. I'd really like to get a malloc_extmem() working for beta3.

Previously I tried to find a way to initialize DMAMEM variables, but ran into compiler limitations with "bss" segments which I couldn't solve.

[PaulStoffregen]

I'm uploading 1.54-beta2 right now, but it's going very slowly. Looks like my ISP is severely throttling. ETA is looking like 2 hours to get it all uploaded.

[defragster]

TeensyDuino 1.54 Beta 2 Published