Teensy 4.1 - Keywords or attributes for code to be executed from RAM (but code bytes written at runtime)

Loxodonta

Member
Hi,
I'm trying to solve a problem concerning the uLisp ARM assembler (see http://www.ulisp.com/show?2YRU) on Teensy 4.1. With the current Teensy toolchain it is not possible (anymore) to get the inline assembler of uLisp to work. The assembler translates mnemonics to machine code at runtime and writes the resulting machine code bytes to a pre-allocated C-array, on the Teensy 4.0/4.1 defined like this:
FASTRUN uint8_t MyCode[CODESIZE] WORDALIGNED;
Writing the code to the FASTRUN section in that way did work with older versions of the toolchain and/or Arduino IDE, but doesn't anymore. Trying to fill this array at runtime now results in a crash. On the other hand, if "MyCode" is not placed into the FASTRUN section, the assembler itself does not crash, the code is written correctly - BUT the crash then occurs as soon as I try to invoke the machine code written into that array.

On other ARM processors the "MyCode" array is pre-defined within in a named RAM section defined like this:
RAMFUNC __attribute__ ((section (".ramfunctions")))
Using this method on the Teensy 4.1 instead of using FASTRUN again results in the assembler itself working fine but a crash when invoking the machine code from within uLisp. Where and how do I need to place this array to be able to 1) fill the array at runtime and 2) execute the bytes written into it as code at runtime?
Any ideas on how to get this back to working state are greatly appreciated! Thanks.
 
You'll have to edit the default MPU config in startup.c in the Teensyduino core files.
To be able to write to FASTRUN memory you would want to change READONLY to READWRITE on this line.
To be able to execute code placed in regular data memory you would want to remove NOEXEC from this line.

Those steps alone may not be enough to make it work correctly; the T4.x has separate data and instruction caches that have to be managed very carefully when writing/executing dynamic code.
 
Wow, that came incredibly quick, thank you - and it did the trick! As far as I can tell from a quick first test, the uLisp assembler (and the compiler) are working again.
Thanks a lot!
 
Back
Top