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

  • have you enabled the RAM drive in your file_config.c?

  • Hi Tamir,

    Yes Base address is 0xA0010 0000 and size is 0x0100 0000 sector 32

    default drive RAM

    In Target i have the default RAM1 start 0xA000 0000 and size 0x10000,

    so i believe the files systems just follows on after the application ram usage.

    Do you have experience of using RAM with RTX and the file system did it work, just trying to make sure not going mad here.

    Its an LPC2468 in case your wondering.

    Thanks
    Darren

  • Always progress in small steps.

    As Tamir notes, you need to configure a RAM drive.

    But you must also configure your processor to make use of the external memory. Specifying the SDRAM in the memory map will not be enough. The memory controller must know that the memory is there, and must be configured to generate constant refreshes of the memory - that is the D as in Dynamic in the SDRAM term.

    Progressing in small steps means that you should first make sure that you have your external memory correctly connected, and the processor initialized to use it before you add the next onion ring and tries to use the memory for a RAM disk. Create a tiny application that initializes everything and then copies information to the external RAM. Then put your processor to sleep for a minute or more and then wake it up and verify that all data is still valid in the RAM.

    You can of course do this test in your current application too, but in that case you should do it before starting up RTX. When you know the RAM works, then you can remove the test code.

  • As Per said, among others make sure that the following

    EMC_SETUP           EQU 1
    

    is setup in your startup file.

  • Hi Per,

    I have configured the external memory (i believe), i do have the none RTX version that works, top example, its just the RTX version that hangs.

    Was just after a confirmation that somebody has something similar running out there.

    Thanks
    Darren

  • Still no joy with the RL file system running in extended SDRAM under RTX, the none RTX version is working fine.

    Will feedback when i get this running under RTX.

    Just after confirmation that somebody has something similar running out there.

    Darren

  • check your memory map. do you see something suspicious?

  • But did you verify that your DRAM area is retaining data, i.e. that you could sleep the processor for a very significant time and then retrieve the data from all parts of the memory.

    The introduction of the RTX will change your access patterns, and even if there is no working refresh, you can keep data alive in DRAM memory by normal accesses.

    In the end, you must be sure that all parts of the DRAM gets refreshed by the special refresh cycles of the DRAM controller - different memory chips requires different "loop length" for these refresh cycles to make sure that all pages of the RAM gets refreshed.

  • Hi Per

    Will double check on RAM parameters, but board has same SDRAM as the embedded artist board (24xx), so i based these on Keil listed example settings.

    RAM is maintaining data in none RTX mode, tested.

    But with RTX kernel goes into Data abort handler, still working on it...

    Thanks
    Darren

  • when in abort mode, check your LR register. it should contain the address of the instruction that caused it.

  • Is the data maintained indefinitely when the memory is not accessed? Note that the DRAM memory can keep the contents for many seconds without accesses at room temperature. I would recommend that you give it several minutes with a sleeping processor before you scan the contents. The retention times in the datasheet have a lot of safety margins and they are specified at maximum temperature. You probably get a factor two extra retention for every 10°C lower temperature, so it is very, very easy to think the refresh is working, when it isn't.

    You have the same memory as a development board, but that does not mean that you have managed to exactly copy the RAM-controller initialization required.

  • The data is being maintained in the RAM, tested in my none RTX mode.

    The data abort i have managed to watch appears to happen when the RTX Kernel is attempting to aquire a mutex, whilst initalising the file system "finit()"

    Data abort:Thumb Instruction at 000021ee, Memory Access at E59FF01AH <-- running in simulator

    Still digging :-)

    Thanks for all the feedback

    Darren

  • have you called 'os_mut_init'...?

  • I didn't think i had to these are not my application mutex's these are system mutex. I would assume the os would create it own on start up as part of the os_sys_init() call?

  • of course. I miss understood your post.