I’ve gotten FreeRTOS running on various ARM and Cortex processors, but now I’m trying to bring it up on a SiLabs C8051F500 (64K Flash, 4K XRAM). I’ve started with the Cygnal demo, which is for a similar processor with ~8K XRAM, but I’m having various weird problems. There might be a problem with my SDCC toolchain: I’m getting memory corruption when calling (some?) library routines (in particular, the memset() where a new task stack is initialized to tskSTACK_FILL_BYTE steps on heap_1.c’s static variables).
I’m currently groveling through the pointer machinery, but wondered if anybody has gotten FreeRTOS running on SiLabs procs other than the F120 that the Cygnal demo is set up for. Any advice, such as “don’t bother, there’s not enough memory to do anything” could save me a few hours of fiddling.
There have been issues reported with the later versions of SDCC - unfortunately I have not got around to looking at this yet as its not one of the most used ports.
You have to recompile the libraries to be re-entrant. The FreeRTOS site links to some libraries that I pre-build several years ago, but I don’t know if they are still compatible with the newer SDCC versions.
Do you have the kernel running before the library problem occurs?
> Do you have the kernel running before the library problem occurs?
No, I’ve printf-debugged / fixed through the mallocs in CreateTask (my single task plus the Idle task) but the first context switch never happens. I don’t have much in the way of debugging capability, so it’s nigh impossible to catch / inspect things as they happen.
Given my trouble with memset(), it seems very likely that I don’t have reentrancy handled right. I skimmed that section in the SDCC docs, but I’m not familiar enough with the 8051 architecture yet to understand how the way SDCC does things, interacts with the way FreeRTOS handles stacks and context switches.
(The 8051 is totally cringe-inducing after playing with ARMs and even the AVR8. Ugh!)
I’ve made some slow progress. I can get the first task running and the timer tick going, but only if I comment out the “vTaskSwitchContext()” in vTimer2ISR(). There’s only one task (not counting the idle task) and it’s higher than idle priority, so the context switch shouldn’t change pxCurrentTCB. The SAVE_CONTEXT and RESTORE_CONTEXT macros appear to be working OK. I guess it’s time to root around in tasks.c…
I had the same problem. It will die at the first context switch regardless of the source of switching. If you use SDCC 2.5.0 with the reentrant library that Richard supplied it works fine. Won’t run with 2.6.0 or above. I have not tried re-compiling the libs but I built a dead simple test program that just increments a counter in each of 2 tasks so it is not calling any lib functions and it still won’t work above 2.5.0. It would be nice to get it working with 2.9.0
Thanks for the confirmation – it’s nice to know that others have had similar problems. I suppose I’ll have to figure out how to use the SDCC simulator & debugger. It’s unlikely that I’ll be able to figure out what’s going on with just printf debugging.
I am currently debugging using the Sililabs IDE that comes with the 8051F120 prototype board. It is fairly good. I have found that the program will run normally through task creation and then starts the scheduler ok. The last task created then runs until either a tick interrupt or other task changing command at which point the stack appears to get bloan away and execution jumps to 0x0000. It may be a problem with malloc and how the initial stack for each task gets created. I want to test what the stacks for each task look like with 2.5.0 and 2.6.0 to see if they are different. If you find anything please post me a note!
Latest: Ran the same code on 2.5.0 and 2.9.0 up through task creation. The initial stacks look completely different. The 2.9.0 stack does not even have the task name in it. Looks like TaskCreate is not working properly. More to come.