This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RL-ARM filesystem and SDRAM

Anybody using the file system with RTX o/s, saving data to SDRAM.

Have board 32MB SDRAM on DYCS0 map the memory in none RTX mode the code runs fine and can read write to files.

In RTX mode application hangs at finit(), when application is stopped its in the DAbt_Handler.

The code none RTX is really simple

int main (void) {

        int i;

        FILE *f_p, *f_rp;
        char line[80];

                while( 0 != finit() );

                i = fformat("R:");


                f_p = fopen("R:\\temp\test.txt", "w" );

                if (f_p != NULL){

                 fputs("Example of a string in ram.\n", f_p);


                 fclose(f_p);

                }

                //re open the file to read back
                f_rp = fopen("R:\\temp\test.txt", "r" );

                if (f_rp != NULL){

                        fgets(line, sizeof(line), f_rp);

                        fclose(f_rp);
                }

}

The RTX version

_task void init (void){


int i;
os_tsk_prio_self (100);
while( 0 != finit() );
i = fformat("R:");
os_tsk_create (timer_task, 40);
os_tsk_delete_self();
}
int main (void) { os_sys_init(init); while(1); }

The have increased the heap size, not using microlib, Imported swi_handler (i have used RTX before and the file system but not to SDRAM, previously use SDCARD).

Just after any pointers if anybody has some to share, bang head is getting painfull.

Thanks
Darren

Parents
  • Hi Tamir,

    You set me thinking, it appears at the moment that
    _mutex_initialize is not being called by the os on start, explains why it then aborts later.

    Back to drg board now with some really vanilla code, i am guessing my other bits using the RTX worked in my earlier test code, as no mutex's used by the o/s.

    I just flicked back to another application i have running on a 2368 (this is a 2468 with the issue), and the _mutex_initialize is called by the o/s just before calling the user initalisation task passed in os_sys_init().

    Thanks again guys.

Reply
  • Hi Tamir,

    You set me thinking, it appears at the moment that
    _mutex_initialize is not being called by the os on start, explains why it then aborts later.

    Back to drg board now with some really vanilla code, i am guessing my other bits using the RTX worked in my earlier test code, as no mutex's used by the o/s.

    I just flicked back to another application i have running on a 2368 (this is a 2468 with the issue), and the _mutex_initialize is called by the o/s just before calling the user initalisation task passed in os_sys_init().

    Thanks again guys.

Children
  • make sure that:
    * you don't use more user timers than are defined in RTX_config.c
    * you don't create more tasks that are defined in RTX_config.c

  • Thanks for the feedback, well i have come to a conclusion.

    It appears that in a system using RTX kernel, the inclusion of finit() alone is not enough. It appears the compiler is optimising out the call to _mutex_initialize to create the system mutex's if no i/o routines are include i.e. fopen() etc.

    Unfortunalty finit() calls _mutex_acquire to get system mutex and so we end in the DAbt_Handler.

    so my build slowly as you go

    __task void init (void){
    os_tsk_prio_self (100);
    while( 0 != finit() );
    fformat("R:");
    os_tsk_create (timer_task, 40);
    os_tsk_delete_self();
    }
    
    

    was doomed to fail. Not really a bug more of a gotcha.

    Cheers
    Darren