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
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.
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