RL-RTX can not work with RL-FlashFs

Thanks a lot.

My application does not use MicroLib.

And what is the following mean?

"Make sure that your SWI handler, which is part of the

startup file, is IMPORTED from RTL."

How to do it. I use the startup file from the keil

example

Thanks a lot.

My application does not use MicroLib.

And what is the following mean?

"Make sure that your SWI handler, which is part of the

startup file, is IMPORTED from RTL."

How to do it. I use the startup file from the keil

example

the (online) manual of RL-ARM on this site explains that clearly. Have a look - if you don't find it post another message.

I am use STM32 mcu.

If check use MicroLib,run OK,but open file return NULL.

Not use MicroLib ,cannot go main().

It's better give me a startup file. or a simple example

which include RL-RTX & RL-FlashFs. That will be great

help.

Email: lihao2@heinfo.net

See this:

www.keil.com/.../rlarm_ar_create_newapp.htm

Modify the device startup file to enable SWI_Handler function:

* Comment out the following line from the startup file:

      SWI_Handler    B    SWI_Handler

* Add the following line to the startup file:

      IMPORT    SWI_Handler

It's now working OK.

Thanks to all who helped me!

The following two file is important,I think:

STM32F10x.s & Retarget.c.

I have almost the same problem but this solution don't do anything for me.

I start my test using Keil\ARM\Boards\Keil\MCB2400\RTX_Blinky examples

I check my option and uncheck Microlib.
I check my LPC2400.s and the modification is done

ie :

SWI_Handler    B    SWI_Handler

is replaced by

IMPORT    SWI_Handler

I can compile and run the example program.

BUT
when I add this code to the main

int main (void) {

        static FILE *f = NULL;

        if (finit() != 0) {
            f = NULL;
            return;
         }
        //f = fopen ("M:\\toto.txt","w");

        //if(f!=NULL)
        //      fclose(f);

        os_sys_init (init);
}

(All necessary flash file (like File_Config.c,File_Config.c,Retarget.c,...) are taken from \Keil\ARM\Boards\Keil\MCB2400\RL\FlashFS\Em_File)

I can't go to the main (in debug mode)

But the very strange thing is that this code work well

   if (finit() != 0) {
            f = NULL;
            return;
         }
    ffind ("M:*.*",&info) == 0);

I look in the info structure and there is all informations on my file

So I think the problem could come from the retarget.c but I don't know what to modify.
and with an example without RTX all work well

Just a question: Where do you "park" your program when you do return from main()?

I don't know much about this. But maybe:

1. In RTX_Conf_LPCxxxx.c, please enable the "Check for the stack overflow". Make sure you provide enough space for all the stacks.

2. os_sys_init() ->

http://www.keil.com/support/man/docs/rlarm/rlarm_os_sys_init.htm

[start]
The os_sys_init function initializes and starts the Real-Time eXecutive (RTX) kernel.

The os_sys_init function does not return. Program execution continues with the task identified by the task argument.
[end]

Since you choose to use an OS on your platform, it is better to initialize and start the (RTX) kernel first, before you do anything else.

First thanks to try to answer to my question
To Per Westermark : I'am not sure to understand what do you really mean. That's not I never get out of the main function, it's I never go in the main function. So I never go to the rest of my program which for the moment is very "light" because I have just an init task which launch a task that switch the led of my demo board.

__task void led (void) {

  LED_Init (); /* Initialize LED display module    */
  for (;;) {
    LED_Out (leds);/* Update LED Driver  */
        leds=leds<<1;
        if(leds==0x10)
                leds=0x01;
    os_dly_wait (20);
  }
}

__task void init (void) {

        static FILE *f = NULL;

        if (finit() == 0) {
        f = fopen ("M:\\toto.txt","w");

        if(f!=NULL)
                fclose(f);
        }
  /* start task led */
  t_led    = os_tsk_create (led, 1);
  os_tsk_delete_self ();
}


int main (void) {

os_sys_init (init);
/* Initialize RTX and start init    */
}

To John Linq :
I have

#ifndef OS_STKCHECK
 #define OS_STKCHECK    1
#endif

but I check I never get into

os_stk_overflow (OS_TID task_id)

So I think there is no stack overflow (and moreover it is a really small program).

next you are right I should do

os_sys_init (init);

before doing everything else so I put the "FlashFS" call in the init task (like I post). but that don't change anything.

When I launch the program in debug mode I found that I go to

void _sys_exit (int return_code) {
   /* Endless loop. */
   while (1);
}

and of course I stay in it because it's a "while(1)" that why I never go to main, I go to _sys_exit before the main function is call

Does the flash file system requires dynamic memory? In that case - have you supplied a large-enough heap?

yes it does. Keil report that you must define at least 0x400 bytes of heap.

Thanks a lot!!
I forgot to set the heap size (it was 0x00) and now it seams to work well!!

Thank you all.

When main() returns:

http://www.keil.com/support/man/docs/armlib/armlib_chdegjfd.htm

__rt_entry

The symbol __rt_entry is the starting point for a program using the ARM C library. Control passes to __rt_entry after all scatter-load regions have been relocated to their execution addresses.

The default implementation of __rt_entry:
1. Sets up the heap and stack.
2. Initializes the C library, by calling __rt_lib_init.
3. Calls main().
4. Shuts down the C library, by calling __rt_lib_shutdown.
5. Exits.

__rt_entry must end with a call to one of the following functions:

exit() Calls atexit()-registered functions and shuts down the library.

__rt_exit() Shuts down the library but does not call atexit() functions.

_sys_exit() Exits directly to the execution environment. It does not shut down the library and does not call atexit() functions. See _sys_exit().

Yes, that was a lot of text - but the interesting thing is what your processor will do if you end your program.

"Exits directly to the execution environment" sounds nice, but without a command line prompt or a GUI in the embedded system, it is normally best to write applications so they never leave main, or so that they get stuck in a busy-loop while waiting for the watchdog to restart.

Hi Per,

Many thanks.

As you may already noticed that, actually, I don't really understand the content of that url/documentation.

I have being curious about why are so many endless-loops there in the source code. Now I realize that, it is there for "waiting for the watchdog to restart".

But I still don't understand what does "shuts down the library" means?

We may only guess what it means to shut down the library. But let's assume that they mean that if you are using a flash file system, they will try to make sure that all changes are flushed to disk before your program dies. If you have the networking library, possibly send out information to close any remaining connections.