Re: dynamic execution of tasks in uC
From: onestone (onestoneXYZ_at_ABCbigpond.net.au)
Date: 06/19/04
- Next message: jetmarc: "Re: My protocol Adressing problem."
- Previous message: Richard: "Re: FreeRTOS and ATMega8"
- In reply to: heiko_greiner_at_hotmail.com: "Re: dynamic execution of tasks in uC"
- Next in thread: heiko_greiner_at_hotmail.com: "Re: dynamic execution of tasks in uC"
- Reply: heiko_greiner_at_hotmail.com: "Re: dynamic execution of tasks in uC"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 19 Jun 2004 15:04:31 GMT
heiko_greiner@hotmail.com wrote:
>>...It is a fairly simple task to do this on any
>>micro that can execute code from RAM. I used this technique on a HC05
>>around 1990, as part of a security system, and use a similar technique
>>now on MSP430's to up date software/implement security functions etc.
>>
>>Al
>
>
> First of all, i meant the hardware required for uCLinux might be to
> expensive for my budget ;-)
>
> Al, do you have a link to a project, using ram (or flash?) for dynamic
> tasks? Or can you try to explain how to implement such a technique ?
>
> thanks,
>
> Heiko.
Hello Heiko. The principles are simple. Take the MSP430 for example,
which I currently use in a lot of products/projects. It can execute code
from RAM. There are many ways to execute external tasks. The mechanism
you use will usually depend upon whether the task request is generated
by the process, or externally. Where I have used this for process
requested tasks I have typically had an external secure memory store
which holds the desired task. Thus the micro itself contains no security
information useful to anyone hacking the system. In it's simplest form
the following hopefully will convey the concept. IT ISN'T MEANT TO BE
WORKING CODE!
;******** COMMS PROTOCOL MESSAGE TYPE CONSTANTS
SENDDATA EQU 01
READDATA EQU 02
SENDSTATUS EQU 03
FETCHTASK EQU 04
ORG RAMSTART
CODEBUFF: DS 512 ;RESERVE 512 BYTES AS CODE BUFFER
TASKQ DS 32 ;RESERVE 16 SLOTS FOR TASK
OTHER VARS..
ORG PROGSTART
RESET:
MOV #RAMEND,SP
CALL #INIT ;PERFORM BASIC START UP
CLR R4 ;R4 RESERVED AS TASKQ POINTER
CLR &TASKQ ;SET NULL TASK IN Q0
MAIN:
CALL #TASKQ(R4) ;EXECUTE THE NEXT TASK
DECD R4
JC MAIN
CLR R4
JMP MAIN
NULLTASK:
RET
/*******************************************************************
ETASK IS A REQUEST TO EXECUTE A TASK STORED EXTERNALLY
IN THIS SIMPLE EXAMPLE THERE IS ONLY PROVISION FOR ONE ETASK.
A CRUDE SINGLE BYTE COMMAND IS SENT TO SOME EXTERNAL SOURCE
INSTRUCTING IT TO DOWNLOAD THE CODE TO BE EXECUTED. THE RECEIVED DATA
WILL BE PLACED IN CODEBUFF. YOU THEN GET TWO CHOICES(AT LEAST).
AFTER SENDING THE COMMAND BYTE. LOOP UNTIL THE CODE IS RECEIVED (FOR
WHEN IT MUST EXECUTE IMMEDIATELY. oR SIMPLY EXIT
AND ALLOW THE RECEIVE PROTOCOL TO PUSH THE NEW TASK ONTO THE
QUEUE.
********************************************************************/
ETASK:
MOV #CODEBUFF,&RX_PTR ;SET RECEIVE DATA POINTER
MOV.B #FETCHTASK,&TXDATA ;DON'T NEED A TASK, PROTOCOL IS ;SINGLE
BYTE FROM MICRO.
RET
/***********************************************************************
RECEIVE MESSAGE STRUCTURE
ADDR 0 MSG TYPE
ADDR 1 DATA LENGTH IN WORDS N
ADDR 2 TASKMSB ;TASK TO BE EXECTUTED UPON DOWNLOAD
ADDR 3 TASKLSB
ADDR 4 DATA
ADDR 5 ...
ADDR 2N+4 ...
ADDR 2N+5 MSB CRC
ADDR 2N+6 LSB CRC
ONCE THE MESSAGE HAS BEEN RECEIVED AND VERIFIED The TASK contained
within the message, actually the address of CODEBUFF, is placed into the
TASKQ.
On most occasions I erase the entire code buffer after completion, so,
if this is the case the message header might include a double task
entry, where the firts task placed on the Q (assuming FILO handling) is
the clean up routine.
Typuically the original ETASK might be placed on the queue by an
external interrupt, such a a key press, or detection of a DALLAS secure
memory device.
This is obviously an over simplified explanation, but most of the
necessary elements are there. Most assemblers will generate code for RAM
based source, but keeping the source relocatable will be necessary
sometimes.
The second method is even more powerful, the originating request is
external. The message protocol for the receiver simply places certain
data from each message in the TASKQ. This could be done EVERY TIME a
message is received, as a simple camouflage method using NULLTASK. Or
may only be done for certain message types.
Of course more than one program or function may be buried in the
downloaded code. For example you may download the code necessary to
re-write internal flash using this method, and at the same time download
a decryption algorithm which takes existing data in FLASH, DECRYPTS IT,
then stores it back where it came from. using micro controlled shut down
you can guarantee reverting the flash upon completion, unless the user
pulls power, or RUN an address translator from RAM, and even if power is
pulled the code will be hard to decipher.
Lots of interesting things you can do with this.
Cheers
Al
- Next message: jetmarc: "Re: My protocol Adressing problem."
- Previous message: Richard: "Re: FreeRTOS and ATMega8"
- In reply to: heiko_greiner_at_hotmail.com: "Re: dynamic execution of tasks in uC"
- Next in thread: heiko_greiner_at_hotmail.com: "Re: dynamic execution of tasks in uC"
- Reply: heiko_greiner_at_hotmail.com: "Re: dynamic execution of tasks in uC"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
