Cubesat Teensy, software uploading

Status
Not open for further replies.
A

afarhan

Member
Hi all,
I have been using Teensy for a while now, mostly on the DSP side. My group is now considering flying the Teensy 3.2 on a cubesat mission that we are planning. For this, we need the ability to upload code in bits and parts (as and when we get access to the satellite overhead). In this context, I have the following questions :
1. Is there a programming support where we can 'assemble' blocks of fresh code in SRAM over various passes and then, move them over to the flash?
2. Is the teensy uploader fault tolerant? What happens if the upload fails half way through?
3. Will Teensy uploader work 1200 baud?
4. Can bootloading be initiated from the code?

- farhan (VU2ESE)
 
So, let me restate the problem definition, now that i dug around the forum a bit more,
The cubesat mission will have most of the telemetry/command code burned-in beforehand. it is the signal handling DSP code that will have to change on the fly. So, it would typically need just about 10K to 20K of code to be redone. This could be done in the following way:
1. use the gcc to compile a function.
2. upload the function over 1200 baud connection (at about 100 bytes per second) in about 3 minutes in an byte array (word aligned)
3. branch the code to checksum and conditionally execute the new code.
any pointers?

afarhan said:
Hi all,
I have been using Teensy for a while now, mostly on the DSP side. My group is now considering flying the Teensy 3.2 on a cubesat mission that we are planning. For this, we need the ability to upload code in bits and parts (as and when we get access to the satellite overhead). In this context, I have the following questions :
1. Is there a programming support where we can 'assemble' blocks of fresh code in SRAM over various passes and then, move them over to the flash?
2. Is the teensy uploader fault tolerant? What happens if the upload fails half way through?
3. Will Teensy uploader work 1200 baud?
4. Can bootloading be initiated from the code?

- farhan (VU2ESE)
Click to expand...
 
I fear that it's rather difficult to replace code on the fly, especially since you would have to upload each time a newly compiled and linked entire hex file, since the latter don't allow dynamic linking.

I'd rather suggest as a solution to make your DSP code highly parametrable with the parameters in the Teensy's EEPROM and include code to update these parameters in the EEPROM via a serial connection.
 
Our idea is to be able to experiment with various modes. It wouldn't be possible to parameterize something to, for instance, decode FT8 or track a PSK31 as it dopplers across the pass-band. We will need to write code to do that.
Until now, each revision of DSP has needed a new satellite launch to try these things out. We are trying to change that to, just waiting for a pass. It can be easily done on the RPi Zero, at about twice the current draw. I am more inclined to make a case to the engineering team for Teensy as it is much easier to program and test on this platform.
 
One method that was mentioned recently was to have a Teensy 3.6 that uses the USB host interface to download HEX files to the Teensy 3.2 (or 3.5/3.6):

One method that I've done in the distant past is to abstract all of the Teensy calls into calls through pointers to functions and create a structure that has all of the appropriate pointers to functions and pointers to data collected together. You then write your library code to only use PC relative addressing and do everything through the pointers passed in the structure. You then use the command line compiler to create an object file that has the initial function at address 0 (presumably compile several modules, and link them together and make a HEX file from the objects). You use a static array in your code and download the code to that array. I'm not that familiar with ARM processors, but you may need to issue some instructions to flush the I/D-caches. You construct a pointer to a function at the address of the static memory, and pass in the structure that contains all of the interfaces.

If you hack up the linker script for Teensy (presumably using an edited boards.txt file) to put the static data used for the code in a specific location, you can eliminate the need to use pc-relative addressing.
 
Status
Not open for further replies.
Back
Top