AW: [ECOS] FLASH access from user program

AW: [ECOS] FLASH access from user program

[Neundorf, Alexander]

Hi,

> Von: ecos-discuss-owner@ecos.sourceware.org
> 
> I would like to do functions similar to "fis delete" and "fis create"
> from an eCos user program.
> 
> How can I get access to the FLASH?
> Are there system calls for this, or do I have to move a lot of RedBoot
> code into my program?
> 
> Or are there other possibilities?
> 
> All input is welcome.


please have a look at the thread "contributing a failsafe update meachanism for FIS from within ecos applications" 
on this page http://ecos.sourceware.org/ml/ecos-devel/2004-10/ .
Is this the type of functionality you need ?

Bye
Alex

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Thread not starting!

[Raja Mallik]

hi 
 
I am trying to run a thread application.by calling cyg_thread_create
function.
 
In the configtool, I have enabled "ASSERT" and while loading the
application to my board, I get this messages!
 
I am not able understand why the thread is not getting started..
 
Kindly share your views..
 
Regards
raja
 

 

 

Creating the Background Thread

TRACE: mlqueue.cxx [ 578]
Cyg_SchedThread_Implementation::Cyg_SchedThread_Implementation() 

{{enter

TRACE: mlqueue.cxx [ 578]
Cyg_SchedThread_Implementation::Cyg_SchedThread_Implementation() 

((sched_info=00000007))

TRACE: mlqueue.cxx [ 592]
Cyg_SchedThread_Implementation::Cyg_SchedThread_Implementation() 

}}return void

TRACE: sched.cxx [ 468] Cyg_SchedThread::Cyg_SchedThread() 

{{enter

TRACE: sched.cxx [ 468] Cyg_SchedThread::Cyg_SchedThread() 

}}RETURNING UNSET!

TRACE: clock.cxx [ 650] Cyg_Alarm::Cyg_Alarm() 

{{enter

TRACE: clock.cxx [ 650] Cyg_Alarm::Cyg_Alarm() 

}}RETURNING UNSET!

TRACE: thread.cxx [ 200] Cyg_Thread::Cyg_Thread() 

{{enter

TRACE: mlqueue.cxx [ 420] void
Cyg_Scheduler_Implementation::register_thread() 

{{enter

TRACE: mlqueue.cxx [ 420] void
Cyg_Scheduler_Implementation::register_thread() 

((thread=000786cc))

TRACE: mlqueue.cxx [ 423] void
Cyg_Scheduler_Implementation::register_thread() 

}}return void

TRACE: thread.cxx [ 238] Cyg_Thread::Cyg_Thread() 

}}return void

TRACE: thread.cxx [ 611] void Cyg_Thread::resume() 

{{enter

TRACE: mlqueue.cxx [ 202] void
Cyg_Scheduler_Implementation::add_thread() 

{{enter

TRACE: mlqueue.cxx [ 202] void
Cyg_Scheduler_Implementation::add_thread() 

((thread=000786cc))

TRACE: mlqueue.cxx [ 263] void
Cyg_Scheduler_Implementation::add_thread() 

}}return void

TRACE: thread.cxx [ 642] void Cyg_Thread::resume() 

}}return void



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Thread not starting!

[Gary Thomas]

On Mon, 2005-06-06 at 16:01 +0530, Raja Mallik wrote:
> hi 
>  
> I am trying to run a thread application.by calling cyg_thread_create
> function.
>  
> In the configtool, I have enabled "ASSERT" and while loading the
> application to my board, I get this messages!
>  
> I am not able understand why the thread is not getting started..
>  
> Kindly share your views..

Did you start the scheduler?  Maybe you could show us your code 
instead of just this trace (it's hard to tell what you've done 
wrong, all we can see are the results)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Thread not starting!

[Raja Mallik]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Hi again, 

Please find the tarces.txt and twothreads.c file attaced
Let me know where am I going wrong?

regards
Raja
On Mon, 2005-06-06 at 16:14, Gary Thomas wrote:
> On Mon, 2005-06-06 at 16:01 +0530, Raja Mallik wrote:
> > hi 
> >  
> > I am trying to run a thread application.by calling cyg_thread_create
> > function.
> >  
> > In the configtool, I have enabled "ASSERT" and while loading the
> > application to my board, I get this messages!
> >  
> > I am not able understand why the thread is not getting started..
> >  
> > Kindly share your views..
> 
> Did you start the scheduler?  Maybe you could show us your code 
> instead of just this trace (it's hard to tell what you've done 
> wrong, all we can see are the results)

[-- Attachment #2: traces.txt --]
[-- Type: text/plain, Size: 10212 bytes --]

Entering twothreads' cyg_user_start() function
TRACE: mutex.cxx           [ 382] void Cyg_Mutex::unlock()                      
                                                           {{enter
TRACE: mutex.cxx           [ 447] void Cyg_Mutex::unlock()                      
                                                           }}return void
TRACE: mutex.cxx           [ 382] void Cyg_Mutex::unlock()                      
                                                           {{enter
TRACE: sched.cxx           [ 705] void Cyg_SchedThread::disinherit_priority()   
                                                             {{enter
TRACE: sched.cxx           [ 628] void Cyg_SchedThread::clear_inherited_priority
()                                                             {{enter
TRACE: sched.cxx           [ 628] void Cyg_SchedThread::clear_inherited_priority
()                                                             }}RETURNING UNSET
!
TRACE: sched.cxx           [ 705] void Cyg_SchedThread::disinherit_priority()   
                                                             }}RETURNING UNSET!
TRACE: mutex.cxx           [ 447] void Cyg_Mutex::unlock()                      
                                                           }}return void
TRACE: fputc.cxx           [  93] fputc()                                       
                                                         }}wrote char 10
TRACE: mutex.cxx           [  92] Cyg_Mutex::Cyg_Mutex()                        
                                                         {{enter
TRACE: mutex.cxx           [ 130] Cyg_Mutex::Cyg_Mutex()                        
                                                         }}return void
TRACE: mlqueue.cxx         [ 578] Cyg_SchedThread_Implementation::Cyg_SchedThrea
d_Implementation()                                       {{enter
TRACE: mlqueue.cxx         [ 578] Cyg_SchedThread_Implementation::Cyg_SchedThrea
d_Implementation()                                         ((sched_info=00000004
))
TRACE: mlqueue.cxx         [ 592] Cyg_SchedThread_Implementation::Cyg_SchedThrea
d_Implementation()                                       }}return void
TRACE: sched.cxx           [ 468] Cyg_SchedThread::Cyg_SchedThread()            
                                                         {{enter
TRACE: sched.cxx           [ 468] Cyg_SchedThread::Cyg_SchedThread()            
                                                         }}RETURNING UNSET!
TRACE: clock.cxx           [ 650] Cyg_Alarm::Cyg_Alarm()                        
                                                         {{enter
TRACE: clock.cxx           [ 650] Cyg_Alarm::Cyg_Alarm()                        
                                                         }}RETURNING UNSET!
TRACE: thread.cxx          [ 200] Cyg_Thread::Cyg_Thread()                      
                                                         {{enter
TRACE: mlqueue.cxx         [ 420] void Cyg_Scheduler_Implementation::register_th
read()                                                     {{enter
TRACE: mlqueue.cxx         [ 420] void Cyg_Scheduler_Implementation::register_th
read()                                                       ((thread=00048600))
TRACE: mlqueue.cxx         [ 423] void Cyg_Scheduler_Implementation::register_th
read()                                                     }}return void
TRACE: thread.cxx          [ 238] Cyg_Thread::Cyg_Thread()                      
                                                         }}return void
TRACE: mlqueue.cxx         [ 578] Cyg_SchedThread_Implementation::Cyg_SchedThrea
d_Implementation()                                       {{enter
TRACE: mlqueue.cxx         [ 578] Cyg_SchedThread_Implementation::Cyg_SchedThrea
d_Implementation()                                         ((sched_info=00000004
))
TRACE: mlqueue.cxx         [ 592] Cyg_SchedThread_Implementation::Cyg_SchedThrea
d_Implementation()                                       }}return void
TRACE: sched.cxx           [ 468] Cyg_SchedThread::Cyg_SchedThread()            
                                                         {{enter
TRACE: sched.cxx           [ 468] Cyg_SchedThread::Cyg_SchedThread()            
                                                         }}RETURNING UNSET!
TRACE: clock.cxx           [ 650] Cyg_Alarm::Cyg_Alarm()                        
                                                         {{enter
TRACE: clock.cxx           [ 650] Cyg_Alarm::Cyg_Alarm()                        
                                                         }}RETURNING UNSET!
TRACE: thread.cxx          [ 200] Cyg_Thread::Cyg_Thread()                      
                                                         {{enter
TRACE: mlqueue.cxx         [ 420] void Cyg_Scheduler_Implementation::register_th
read()                                                     {{enter
TRACE: mlqueue.cxx         [ 420] void Cyg_Scheduler_Implementation::register_th
read()                                                       ((thread=000486f0))
TRACE: mlqueue.cxx         [ 423] void Cyg_Scheduler_Implementation::register_th
read()                                                     }}return void
TRACE: thread.cxx          [ 238] Cyg_Thread::Cyg_Thread()                      
                                                         }}return void
TRACE: thread.cxx          [ 611] void Cyg_Thread::resume()                     
                                                         {{enter
TRACE: mlqueue.cxx         [ 202] void Cyg_Scheduler_Implementation::add_thread(
)                                                          {{enter
TRACE: mlqueue.cxx         [ 202] void Cyg_Scheduler_Implementation::add_thread(
)                                                            ((thread=00048600))
TRACE: mlqueue.cxx         [ 263] void Cyg_Scheduler_Implementation::add_thread(
)                                                          }}return void
TRACE: thread.cxx          [ 642] void Cyg_Thread::resume()                     
                                                         }}return void
TRACE: thread.cxx          [ 611] void Cyg_Thread::resume()                     
                                                         {{enter
TRACE: mlqueue.cxx         [ 202] void Cyg_Scheduler_Implementation::add_thread(
)                                                          {{enter
TRACE: mlqueue.cxx         [ 202] void Cyg_Scheduler_Implementation::add_thread(
)                                                            ((thread=000486f0))
TRACE: mlqueue.cxx         [ 263] void Cyg_Scheduler_Implementation::add_thread(
)                                                          }}return void
TRACE: thread.cxx          [ 642] void Cyg_Thread::resume()                     
                                                         }}return void
TRACE: sched.cxx           [ 318] static void Cyg_Scheduler::start()            
                                                         {{enter
TRACE: sched.cxx           [ 344] static void Cyg_Scheduler::start_cpu()        
                                                           {{enter
TRACE: mlqueue.cxx         [ 119] Cyg_Thread* Cyg_Scheduler_Implementation::sche
dule()                                                       {{enter
TRACE: mlqueue.cxx         [ 192] Cyg_Thread* Cyg_Scheduler_Implementation::sche
dule()                                                       }}returning thread 
00048600
TRACE: strlen.cxx          [  80] __strlen()                                    
                                                             {{enter
TRACE: strlen.cxx          [  80] __strlen()                                    
                                                               ((s=000413fc))
TRACE: strlen.cxx          [ 127] __strlen()                                    
                                                             }}returning length 
15
TRACE: mutex.cxx           [ 216] cyg_bool Cyg_Mutex::lock()                    
                                                             {{enter
TRACE: mutex.cxx           [ 322] cyg_bool Cyg_Mutex::lock()                    
                                                             }}returning 1
TRACE: mutex.cxx           [ 382] void Cyg_Mutex::unlock()                      
                                                             {{enter
TRACE: sched.cxx           [ 705] void Cyg_SchedThread::disinherit_priority()   
                                                               {{enter
TRACE: sched.cxx           [ 628] void Cyg_SchedThread::clear_inherited_priority
()                                                               {{enter
TRACE: sched.cxx           [ 628] void Cyg_SchedThread::clear_inherited_priority
()                                                               }}RETURNING UNS
ET!
TRACE: sched.cxx           [ 705] void Cyg_SchedThread::disinherit_priority()   
                                                               }}RETURNING UNSET
!
TRACE: mutex.cxx           [ 447] void Cyg_Mutex::unlock()                      
                                                             }}return void
TRACE: fputc.cxx           [  78] fputc()                                       
                                                             {{enter
TRACE: fputc.cxx           [  78] fputc()                                       
                                                               ((c = 10, stream=
00045fcc))
TRACE: mutex.cxx           [ 216] cyg_bool Cyg_Mutex::lock()                    
                                                               {{enter
TRACE: mutex.cxx           [ 322] cyg_bool Cyg_Mutex::lock()                    
                                                               }}returning 1
TRACE: mutex.cxx           [ 216] cyg_bool Cyg_Mutex::lock()                    
                                                               {{enter
TRACE: mutex.cxx           [ 322] cyg_bool Cyg_Mutex::lock()                    
                                                               }}returning 1
eCos Started...

[-- Attachment #3: twothreads.c --]
[-- Type: text/x-c, Size: 1655 bytes --]

#include <cyg/kernel/kapi.h>

#include <stdio.h>
#include <math.h>
#include <stdlib.h>

/* now declare (and allocate space for) some kernel objects,
   like the two threads we will use */
cyg_thread thread_s[2];		/* space for two thread objects */

char stack[2][4096];		/* space for two 4K stacks */

/* now the handles for the threads */
cyg_handle_t simple_threadA, simple_threadB;

/* and now variables for the procedure which is the thread */
cyg_thread_entry_t simple_program;

/* and now a mutex to protect calls to the C library */
cyg_mutex_t cliblock;

/* we install our own startup routine which sets up threads */
void cyg_user_start(void)
{
  printf("Entering twothreads' cyg_user_start() function\n");

  cyg_mutex_init(&cliblock);

  cyg_thread_create(4, simple_program, (cyg_addrword_t) 0,
		    "Thread A", (void *) stack[0], 4096,
		    &simple_threadA, &thread_s[0]);
  cyg_thread_create(4, simple_program, (cyg_addrword_t) 1,
		    "Thread B", (void *) stack[1], 4096,
		    &simple_threadB, &thread_s[1]);

  cyg_thread_resume(simple_threadA);
  cyg_thread_resume(simple_threadB);
}

/* this is a simple program which runs in a thread */
void simple_program(cyg_addrword_t data)
{
  int message = (int) data;
  int delay;

  printf("Beginning execution; thread data is %d\n", message);

  cyg_thread_delay(200);

  for (;;) {
    delay = 200 + (rand() % 50);

    /* note: printf() must be protected by a
       call to cyg_mutex_lock() */
    cyg_mutex_lock(&cliblock); {
      printf("Thread %d: and now a delay of %d clock ticks\n",
	     message, delay);
    }
    cyg_mutex_unlock(&cliblock);
    cyg_thread_delay(delay);
  }
}


[-- Attachment #4: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Thread not starting!

[Gary Thomas]

On Mon, 2005-06-06 at 17:08 +0530, Raja Mallik wrote:
> Hi again, 
> 
> Please find the tarces.txt and twothreads.c file attaced
> Let me know where am I going wrong?
> 
> regards
> Raja
> On Mon, 2005-06-06 at 16:14, Gary Thomas wrote:
> > On Mon, 2005-06-06 at 16:01 +0530, Raja Mallik wrote:
> > > hi 
> > >  
> > > I am trying to run a thread application.by calling cyg_thread_create
> > > function.
> > >  
> > > In the configtool, I have enabled "ASSERT" and while loading the
> > > application to my board, I get this messages!
> > >  
> > > I am not able understand why the thread is not getting started..
> > >  
> > > Kindly share your views..
> > 
> > Did you start the scheduler?  Maybe you could show us your code 
> > instead of just this trace (it's hard to tell what you've done 
> > wrong, all we can see are the results)

How did you configure your kernel (what template did you use)?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Thread not starting!

[Raja Mallik]

Hi again, 

We have use "default" option as template!

these are the following packages:

here you see the "ARM9 SCP develboard" which is a customized taken from
exculibar template..

Packages! 

ARM common HAL
ARM9 SCP develboard
ARM9 Variant
c library
common error code support
Dynamic memory allocation
I/o sub system
ISO C and POSIX infrastructure
ISO C library date/time functions
ISO C library general utility functions
ISO C library internationaliztion
ISO C library non local jumps
ISO C library signals
ISO C library standard inpu/output
ISO C library string functions
ISO Environment startup/termintaion
Infrastructure
Math Library
Serial device drivers
Wall clock device framwork
ecos common HAL
eCos Kernel


regards
raja  


On Mon, 2005-06-06 at 17:16, Gary Thomas wrote:
> On Mon, 2005-06-06 at 17:08 +0530, Raja Mallik wrote:
> > Hi again, 
> > 
> > Please find the tarces.txt and twothreads.c file attaced
> > Let me know where am I going wrong?
> > 
> > regards
> > Raja
> > On Mon, 2005-06-06 at 16:14, Gary Thomas wrote:
> > > On Mon, 2005-06-06 at 16:01 +0530, Raja Mallik wrote:
> > > > hi 
> > > >  
> > > > I am trying to run a thread application.by calling cyg_thread_create
> > > > function.
> > > >  
> > > > In the configtool, I have enabled "ASSERT" and while loading the
> > > > application to my board, I get this messages!
> > > >  
> > > > I am not able understand why the thread is not getting started..
> > > >  
> > > > Kindly share your views..
> > > 
> > > Did you start the scheduler?  Maybe you could show us your code 
> > > instead of just this trace (it's hard to tell what you've done 
> > > wrong, all we can see are the results)
> 
> How did you configure your kernel (what template did you use)?


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Thread not starting!

[Gary Thomas]

On Mon, 2005-06-06 at 17:27 +0530, Raja Mallik wrote:
> Hi again, 
> 
> We have use "default" option as template!
> 
> these are the following packages:
> 
> here you see the "ARM9 SCP develboard" which is a customized taken from
> exculibar template..
> 

Have you verified that the standard tests run?  Since this is a
"customized" port, you should do that first.  If problems are
experienced, then you'll know what to look at.

> Packages! 
> 
> ARM common HAL
> ARM9 SCP develboard
> ARM9 Variant
> c library
> common error code support
> Dynamic memory allocation
> I/o sub system
> ISO C and POSIX infrastructure
> ISO C library date/time functions
> ISO C library general utility functions
> ISO C library internationaliztion
> ISO C library non local jumps
> ISO C library signals
> ISO C library standard inpu/output
> ISO C library string functions
> ISO Environment startup/termintaion
> Infrastructure
> Math Library
> Serial device drivers
> Wall clock device framwork
> ecos common HAL
> eCos Kernel
> 
> 
> regards
> raja  
> 
> 
> On Mon, 2005-06-06 at 17:16, Gary Thomas wrote:
> > On Mon, 2005-06-06 at 17:08 +0530, Raja Mallik wrote:
> > > Hi again, 
> > > 
> > > Please find the tarces.txt and twothreads.c file attaced
> > > Let me know where am I going wrong?
> > > 
> > > regards
> > > Raja
> > > On Mon, 2005-06-06 at 16:14, Gary Thomas wrote:
> > > > On Mon, 2005-06-06 at 16:01 +0530, Raja Mallik wrote:
> > > > > hi 
> > > > >  
> > > > > I am trying to run a thread application.by calling cyg_thread_create
> > > > > function.
> > > > >  
> > > > > In the configtool, I have enabled "ASSERT" and while loading the
> > > > > application to my board, I get this messages!
> > > > >  
> > > > > I am not able understand why the thread is not getting started..
> > > > >  
> > > > > Kindly share your views..
> > > > 
> > > > Did you start the scheduler?  Maybe you could show us your code 
> > > > instead of just this trace (it's hard to tell what you've done 
> > > > wrong, all we can see are the results)
> > 
> > How did you configure your kernel (what template did you use)?
> 
> 
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Thread not starting!

[Raja Mallik]

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

Hi Again, 

following are the standard test results

The following tests taken from ecos packages and examples are OK
bin_sem0,cnt_sem0,clock0,intr0,kclock0,kflag0,kintr0,ksem0,kthread0,thread0,mutex0

All other kernel tests are failing.
All are generating same type of failures and the traces of that failures
are attached

regards
raja





On Mon, 2005-06-06 at 17:54, Gary Thomas wrote:
> On Mon, 2005-06-06 at 17:27 +0530, Raja Mallik wrote:
> > Hi again, 
> > 
> > We have use "default" option as template!
> > 
> > these are the following packages:
> > 
> > here you see the "ARM9 SCP develboard" which is a customized taken from
> > exculibar template..
> > 
> 
> Have you verified that the standard tests run?  Since this is a
> "customized" port, you should do that first.  If problems are
> experienced, then you'll know what to look at.
> 
> > Packages! 
> > 
> > ARM common HAL
> > ARM9 SCP develboard
> > ARM9 Variant
> > c library
> > common error code support
> > Dynamic memory allocation
> > I/o sub system
> > ISO C and POSIX infrastructure
> > ISO C library date/time functions
> > ISO C library general utility functions
> > ISO C library internationaliztion
> > ISO C library non local jumps
> > ISO C library signals
> > ISO C library standard inpu/output
> > ISO C library string functions
> > ISO Environment startup/termintaion
> > Infrastructure
> > Math Library
> > Serial device drivers
> > Wall clock device framwork
> > ecos common HAL
> > eCos Kernel
> > 
> > 
> > regards
> > raja  
> > 
> > 
> > On Mon, 2005-06-06 at 17:16, Gary Thomas wrote:
> > > On Mon, 2005-06-06 at 17:08 +0530, Raja Mallik wrote:
> > > > Hi again, 
> > > > 
> > > > Please find the tarces.txt and twothreads.c file attaced
> > > > Let me know where am I going wrong?
> > > > 
> > > > regards
> > > > Raja
> > > > On Mon, 2005-06-06 at 16:14, Gary Thomas wrote:
> > > > > On Mon, 2005-06-06 at 16:01 +0530, Raja Mallik wrote:
> > > > > > hi 
> > > > > >  
> > > > > > I am trying to run a thread application.by calling cyg_thread_create
> > > > > > function.
> > > > > >  
> > > > > > In the configtool, I have enabled "ASSERT" and while loading the
> > > > > > application to my board, I get this messages!
> > > > > >  
> > > > > > I am not able understand why the thread is not getting started..
> > > > > >  
> > > > > > Kindly share your views..
> > > > > 
> > > > > Did you start the scheduler?  Maybe you could show us your code 
> > > > > instead of just this trace (it's hard to tell what you've done 
> > > > > wrong, all we can see are the results)
> > > 
> > > How did you configure your kernel (what template did you use)?
> > 
> > 

[-- Attachment #2: 1.txt --]
[-- Type: text/plain, Size: 2428 bytes --]

TRACE: mutex.cxx           [ 382] void Cyg_Mutex::unlock()                      
                                                               {{enter
TRACE: mutex.cxx           [ 447] void Cyg_Mutex::unlock()                      
                                                               }}return void
TRACE: mutex.cxx           [ 382] void Cyg_Mutex::unlock()                      
                                                               {{enter
TRACE: sched.cxx           [ 705] void Cyg_SchedThread::disinherit_priority()   
                                                                 {{enter
TRACE: sched.cxx           [ 628] void Cyg_SchedThread::clear_inherited_priority
()                                                                 {{enter
TRACE: sched.cxx           [ 628] void Cyg_SchedThread::clear_inherited_priority
()                                                                 }}RETURNING U
NSET!
TRACE: sched.cxx           [ 705] void Cyg_SchedThread::disinherit_priority()   
                                                                 }}RETURNING UNS
ET!
TRACE: mutex.cxx           [ 447] void Cyg_Mutex::unlock()                      
                                                               }}return void
TRACE: fputc.cxx           [  93] fputc()                                       
                                                             }}wrote char 10
TRACE: hal_misc.c          [ 211] hal_arch_default_isr()                        
                                                             'Interrupt: 22'
TRACE: hal_misc.c          [ 188] hal_default_isr()                             
                                                             'Interrupt: 22, Dat
a: 0x00000000'
TRACE: hal_misc.c          [ 211] hal_arch_default_isr()                        
                                                             'Interrupt: 22'
TRACE: hal_misc.c          [ 188] hal_default_isr()                             
                                                             'Interrupt: 22, Dat
a: 0x00000000'
TRACE: hal_misc.c          [ 211] hal_arch_default_isr()                        
                                                             'Interrupt: 22'
TRACE: hal_misc.c          [ 188] hal_default_isr()                             
                                                             'Interrupt: 22, Dat
a: 0x00000000'


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: AW: [ECOS] FLASH access from user program

[Hans Berglund]

Hi

Thank you for the information. It was a long thread, and I haven't read
it all yet. It looks like what I am looking for. What is the difference
in this mechanism and the CYGNUM_CALL_IF_FLASH_FIS_OP virtual vector?

Hans


Neundorf, Alexander wrote:
> Hi,
> 
> 
>>Von: ecos-discuss-owner@ecos.sourceware.org
>>
>>I would like to do functions similar to "fis delete" and "fis create"
>>from an eCos user program.
>>
>>How can I get access to the FLASH?
>>Are there system calls for this, or do I have to move a lot of RedBoot
>>code into my program?
>>
>>Or are there other possibilities?
>>
>>All input is welcome.
> 
> 
> 
> please have a look at the thread "contributing a failsafe update meachanism for FIS from within ecos applications" 
> on this page http://ecos.sourceware.org/ml/ecos-devel/2004-10/ .
> Is this the type of functionality you need ?
> 
> Bye
> Alex
> 
> 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: AW: [ECOS] FLASH access from user program

[Hans Berglund]

Hi again

I have read the thread, and found that this is what I need. The virtual
vector interface currently implements read only.

But what was the conclusion of the thread? Is it now implemented in
eCos, or do I have to get some files from you to add to my application?

I read a suggestion of putting the flash updating into the virtual
vector interface. Is this implemented?

BTW: It seems that a lot of effort is put into this to get it safe.

Hans


Neundorf, Alexander wrote:
> Hi,
> 
> 
>>Von: ecos-discuss-owner@ecos.sourceware.org
>>
>>I would like to do functions similar to "fis delete" and "fis create"
>>from an eCos user program.
>>
>>How can I get access to the FLASH?
>>Are there system calls for this, or do I have to move a lot of RedBoot
>>code into my program?
>>
>>Or are there other possibilities?
>>
>>All input is welcome.
> 
> 
> 
> please have a look at the thread "contributing a failsafe update meachanism for FIS from within ecos applications" 
> on this page http://ecos.sourceware.org/ml/ecos-devel/2004-10/ .
> Is this the type of functionality you need ?
> 
> Bye
> Alex
> 
> 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss