native application loading?

Status
Not open for further replies.
pix-os

pix-os

Well-known member
hi all, i was wondering if the teensy 3.1/3.2 could execute from RAM.

if so, i'd love to collaborate with a few others to create a custom port of contiki os for the teensy 3.
i have done a quick look at contiki os, and there's luckily no asm code (from my observation).
it's all makefiles and c(++) code, so we'd have to port almost everything :(
but i'm sure it will be a great learning curve :)

i assume you wonder why i want this: so i don't have to reflash the mcu every time, but simply load apps from a microSD.

link to their site: http://www.contiki-os.org/
and their github repo: https://github.com/contiki-os/contiki

p.s. if this is the wrong forum, please move the topic to the right place :)
 
Common practice is to update new code version into flash as it doesn't change often after original development. Often, code is too large to fit into RAM.
And Arduino's tool chain doesn't have the option for code in RAM. For 100% of code in RAM, a special linker script file would be needed.

Of course, some code in flash is needed to initialize, and this gets complicated with C++ initializers and class constructors, and initialized variables, etc.
All in all, not worth it.
 
Last edited:
hm... then i wonder why pebble does it for their systems? i mean the pebble classic has 24kb for user applications, and alot of stuff has been developed to fit in that amount of RAM.

EDIT:
besides, i have already decided i want this, mainly as a learning curve. so it's not on why not to do this, but how to archieve this, and perhaps form a team with some others.
 
Last edited:
Assuming you mean the Pebble watch? Looks like they have a development scheme for their watch faces and maybe grabbing web data? One programming option is JavaScript - which is I read right precludes using Android/apple mobile interface? Then they have c of some sort? Didn't see enough detail to see how that is done - but assume it is mature enough to have the mobile interface? They have some work in that.

Don't know what processor they use. Is the 24KB free ram and code space? In ram it would go away without power - so they have a battery sipping hardware setup - or the code is actually stored in battery backed ram or secondary flash? Does Pebble run on Contiki? Contiki Memory: "A typical system with full IPv6 networking with sleepy routers and RPL routing needs less than 10 k RAM and 30 k ROM." Though the supported hardware list isn't telling/encouraging to me: TI, Atmel, 1 each [PIC, Freescale, 6502] :: http://www.contiki-os.org/hardware.html. Contiki blog has one August 2015 entry after this: "A big step for Contiki: built-in encryption - Oct 08, 2014"

You only say you don't want to flash for new code - do you want OTA type updates or to just selectively load apps from SD and run them? I don't see the nature or complexity of the app indicated? Teensy could handle this but would take some infrastructure and work to get there and may be more power than needed? Does it need a radio system for IOT'ing? Some of this could be done on an ESP8266 system that has a native radio and available Arduino IDE support with OTA code upload.
 
yes i mean the pebble watch, you can program apps offline or on cloudpebble (using C or javascript), while loading and putting them into the onboard spi ram goes by bluetooth. the original pebble runs on an stm32 cortex m0+ mcu (i think it was a stm32f2), and they run a custom port of freertos, but with a custom addition of application loading.
24kb ram is not code space, as it flashed the application code on a spi flash chip (meaning apps run stand alone from a smartphone, but can co-operate with one).

i want to run a bare bones system, and i said contiki os because it has native application loading built in,
doesn't mean i want to stick to contiki os though.

i want to load them from a microsd device so i won't need a computer at hand to run my custom applications.
and true, system updates themselfs would still require a reflash on the mcu.
 
You certainly can run code from RAM. The normal way involves adding FASTRUN to a function definition, which causes the linker to place that function into RAM, and a copy of its image into a region of flash that's copied to RAM by the startup code. Of course, that's for a normal monolithic firmware image, not loadable modules like you want. Still, I'd recommend you at least give this a try to see if working. Maybe it'll help a little?

Making loadable modules will require creating a different linker script. You'll have to choose a region in the 64K RAM where your program's code will go, and where it's data will go. In Teensy 3.2, the RAM is implemented in 2 regions with 2 separate buses. 1FFF8000 to 1FFFFFFF is best for code execution and DMA. 20000000 to 20007FFF is best for variables and the stack. You could pretty easily choose 1FFFA000 to 1FFFFFFF (24 kbytes) for loading your modules. You'll just need to be careful to verify your loader doesn't need that region.

In principle, the idea is pretty simple. Just read the binary image into RAM. Assuming the image has been compiled properly to execute from that location, all you need to do is call it. Converting an arbitrary memory location, like an array of data, into a C function pointer is a bit tricky. Cortex-M processors require the LSB to be set. You can find an example buried inside eeprom.c.

https://github.com/PaulStoffregen/cores/blob/master/teensy3/eeprom.c#L90

Presumably your modules will be able to rely on the loader to set up hardware. But you'll need to do some things yourself, like remapping the interrupt vectors by writing to SBC_VTOR.

What you'll gain from all this, I really don't know. But this question has some up a few times. You can probably find similar answers if you search enough. As far as I know, despite a few people who've said they were going to do this, nobody has actually published any working code. If you do get this running, I hope you'll share what you learn and maybe even skeleton code?
 
Well one way of doing this to set up a structure that contains the address of every function you use externally and every data item. You fill this structure in, and pass it to the function as an argument after you load it into memory. You would need to create your own linker map, and only call through the pointers in the structure whose address was passed in. This way, you don't have the problem of replacing the current data that is executing. You would not need to change interrupt vectors, etc. However, it will force you to code things explicitly for the environment. I would have a version number or data string (such as using the pre-defined __DATE__ and __TIME__ string macros), and if the code that you are attempting to load does not use the right values, don't load it in.
 
thanks for the information all! :)

@paul , you said nobody has released their code for running code from RAM? well, i sort of did it with the arduino DUE before with porting code found on the internet. https://github.com/Pix-OS/arduino_due_ram_execution

and to be honest, it's not for myself, but for a team of a few people i'm working with (hence my username :) ), as i'm gathering information on how to do that and pass that on to the team (i'm sort of the project manager :p )

also note: i'm not wanting to recreate pebble's os, but something unique for teensy only with more than 3 people (the current team size).
 
bump:

does anyone know if this will work with a teensy 3.6 having flash as native flash extention? (if he cpu supports it at all)

it's exactly like pebble did it with their smartwatches.

if supported:
how could we achieve this?
 
pix-os said:
how could we achieve this?
Click to expand...

This can work, but there's at least 3 problems you need to solve.

1: The hardest issue is how to reserve a portion of the RAM. The best way would be to edit Teensy's linker script. I'd recommend using the remainder of the 64K below address 0x20000000. Code executes without wait states from that memory. Or you could reassign all the stuff that's normally in the bottom 64K to 0x20000000. That's give you a fixed 64K size for your programs.

2: You need to set up a makefile or build system to compile the programs.

3: 64K is going to feel pretty limiting, unless you can load the flash memory with lots of useful functions. You'll probably need to create a jump table at a fixed address in flash, and a header file for definitions of those functions to be used when compiling the RAM-based code.
 
1: does the teensy 3.6 have an MPU? if so, then i can set it to a specific range, and prevent executing 'protected' flash code (code not in the app api, preventing malicious code to be ran)

2: that won't be that much of a problem, as pebble has their SDK open source, so can start with learning how they did that.

3: 64K for app RAM is the same as a teensy 3.2, which overkill, functions willbe on external qspi flash (with support of execution in place, just like pebble)
 
pix-os said:
1: does the teensy 3.6 have an MPU?
Click to expand...

Yes. It supports 8 regions, where access is allowed if any of the 8 match.

But it's not a MMU (able to translate addresses). It only allows or disallows access for various bus masters based on 8 sets of simple address range rules.

Documentation is in the reference manual, chapter 22 starting on page 449:

http://www.pjrc.com/teensy/K66P144M180SF5RMV2.pdf

3: 64K for app RAM is the same as a teensy 3.2, which overkill, functions willbe on external qspi flash (with support of execution in place, just like pebble)
Click to expand...

Teensy 3.2 has 32K of RAM below 0x20000000, which is optimized for executing code.

Presumably the programs you dynamically load will need to allocate their own static, (maybe) heap, and stack variables in RAM that's separate from the RAM used for executing code.
 
Status
Not open for further replies.
Back
Top