Re: Relocating application architecture and compiler support

From: George Neuner (gneuner2/_at_comcast.net)
Date: 01/24/05 

Date: Mon, 24 Jan 2005 02:24:39 -0500

On Wed, 19 Jan 2005 21:36:56 +0200, Niklas Holsti <nobody@nowhere.fi>
wrote:

>s.subbarayan wrote:
>> Embedded gurus,
>> Can some one advice me how to create relocatable application in C?We
>> are currently working in an application,where we are supposed to test
>> the entire RAM area for physical errors in the chip.We have created
>> our application for this.The problem we are facing is this:
>>
>> Our application sits in a particular location in RAM.The requirement
>> states we have to test entire area of RAM including the location where
>> the code is sitting.(Code in this sense,entire binary image which
>> includes code,data,stack,bss).So we came up with the idea of testing
>> the areas other then where our image sits and then move our image to
>> different location with in RAM which is already tested and then come
>> back to original location.
>
>To me that seems like a complex and risky solution. For an alternative
>solution, and assuming that your memory-testing function can restore the
>original content of each memory location after testing it, how about
>having two copies of the test function in the application? Each copy
>uses its own (small) area of memory. The first copy tests the memory
>(code and data) used by the second copy, and the second copy tests
>everything else, including the first copy but not its own memory. In
>this way, the application can stay in one place, and memory locations
>are always inactive while they are being tested.
>
>If your memory-testing function is complex enough to need a stack, you
>may have to use different stack areas for each copy. A simple testing
>function could be implemented with only registers and static variables
>so it could check the stack area without problems.
>
>I'm assuming that the memory test is done with interrupts disabled and
>only one active thread. If the testing has to be done while the
>application is running, the solution must be very different.

But not too different. It's still a good idea to have two copies of
the test code.

One possibility is an interrupt driven test which incrementally steps
through memory N words at a time. If the target memory location falls
within the test routine itself, a second copy of the test code is
invoked instead. This is easy if checking a single location at each
interrupt. If checking multiple locations each time, you need to be
careful with the test code boundaries.

Another possibility is simply having two identical test routines tied
to different interrupts (or alternating on one interrupt), each of
which can check on each other's code addresses.

George 

-- 
for email reply remove "/" from address

Relevant Pages

  • Re: Need test for program loader accuracy; IPSM
    ... program execution - the same thing that I am doing! ... code on a single memory page and I could tell A ran correctly then I could ... that would at least detect some gross obfuscation. ... hoping for a solution that wouldn't require the test code to be inside the ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Need test for program loader accuracy; IPSM
    ... program execution - the same thing that I am doing! ... code on a single memory page and I could tell A ran correctly then I could ... that would at least detect some gross obfuscation. ... hoping for a solution that wouldn't require the test code to be inside the ...
    (microsoft.public.windowsce.embedded)
  • Re: Need test for program loader accuracy; IPSM
    ... program execution - the same thing that I am doing! ... code on a single memory page and I could tell A ran correctly then I could ... that would at least detect some gross obfuscation. ... hoping for a solution that wouldn't require the test code to be inside the ...
    (microsoft.public.windowsce.platbuilder)
  • [PATCH] spelling fixes: arch/ppc/
    ... then we should use the board info from the bd_t ... In a effort to minimize memory usage for embedded applications, ... + * Interrupt setup and service. ... * Implement errata work arounds for the GT64260A. ...
    (Linux-Kernel)
  • Re: Forth as an operating system
    ... service to I/O events or the lowest OS overhead in general. ... We say that an interrupt cannot be the fastest because it ... We say that multiple memory operations cannot ... ISR are the fastest solution possible. ...
    (comp.lang.forth)