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
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...
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
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.
no prob's..
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.
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