ARM7 STR71x Rowley port

Hi, Sorry if that had already been covered somewhere; if so I didn’t found it. It’s been on week that I try to port freeRTOS on my ST mb393b eval board using Rowley CrossWorks without success so far.
The board is equiped with a STR710FZ2. I have followed the port instruction on freertos.org (but I should have done something wrong) and I have a project with only 1 task that should blink a led (tested ok without the freertos code). For now I am in a stage where the project compile and run, I am able to put a breakpoint in my task (so I assume that the scheduler is started), but when I call vTaskDelay() the application seems to crash. So I suspect that I have done something wrong with the tick timer ISR or the yeld function.
I have based my port on a mix between Str75_GCC Str71x_IAR and LPC2138_Rowley, but I can’t find what is wrong, nor have I the knowledge to debug this kind of problem (I had never touched startup asm before that :-) ) Is there some one with experience on this architecture that had already been thru that ?
(As there is no way to attach files, I can mail port.c, portISR and portmacro.h) Thanks in advance! Quentin

ARM7 STR71x Rowley port

> For now I am in a stage where the project compile and run, I am able to put
> a breakpoint in my task (so I assume that the scheduler is started), It sounds like you are well on the way. > but when
> I call vTaskDelay() the application seems to crash.
>
> So I suspect that I have done something wrong with the tick timer ISR or the
> yeld function. We need to determine what, after hitting the task, is the route cause.  The first thing I would suggest is to stop your task from doing anything, and disable interrupts.  So add something like:
taskDISABLE_INTERRUPTS();
for( ;; ); /* NULL loop. */
at the top of the task.  If the task still executes, sits in the null loop, and does not crash then the next thing to do would be remove the taskDISABLE_INTERRUPTS(); call to see if it is still happy, and to see if the tick interrupt will execute repeatedly. Things to check/note: 1) You set Supervisor mode before calling main(), although I think in this case that must already be true. 2) You set up stacks for at least IRQ and Supervisor modes, other modes if you use them too. 3) You are installing the FreeRTOS SWI handler, and using IRQ interrupts in a FreeRTOS compatible way. Regards.

ARM7 STR71x Rowley port

Hi Richard, Thanks for the quick reply. I’ve done what you suggest, and the task still seem happy even with interrupt enable, loop in the “for” endlessly. About your checklist :
1)  For what I know, yes, I have added “SUPERVISOR_START” to the preprocessor definition, and according the crt0.s that I have used (file provided by rowley to init the uC) the application should be started in supervisor mode. (I will provide I link to my file below). 2) For the stacks, I have added “INITIALIZE_STACKS” in the preprocessor definition, but I don’t know if the rowley’s file initialize them in a freeRTOS friendly way 3) I have modified the STR71xSoftwareLibrary_Startup.s also provided by rowley for the STR71x to point to the vPortYieldProcessor that I have adapted in portISR.c. But I must admit I am not confident at all with ISR definition and the assembly that arround that. For what I know ARM7TDMI can be used with two different interrupt scheme, (on vecotored directly? one vectored thru the IVR?) and I have tried both without success… So I should have setup interrupt wrongly or there is something wrong in my port files (also very likely..).
Here are the file if you (or someone else) have the time to have a look : crt0.s
STR71xSoftwareLibrary_Startup.s
port.c
portISR.c
portmacro.h Again, thanks for your time :-) Quentin Berhet

ARM7 STR71x Rowley port

Codepad seem very slow theses last time, I have reposted the files on ideone : crt0.s
STR71xSoftwareLibrary_Startup.s
port.c
portISR.c
portmacro.h Of course, if there is a need to see another file just let me know. Q.

ARM7 STR71x Rowley port

IRQ interrupts can be implemented in two ways.  1) Save/Restore the task context from a central point, before calling the application code, removing the need for the application interrupt handlers to perform any save or restore operations explicitly.  This allows easier implementation of ISRs, but can be execution time inefficient if not all interrupts have the potential to perform a context switch as the save/restore is executed on each interrupt. 2) Vector directly to an application defined interrupt handler, where the context save/restore is included explicitly in the application defined ISR definition.  This can be more execution time efficient where not all interrupts have the potential to perform a context switch, but less code size efficient as the context save/restore code will be duplicated in each ISR definition that has the potential to perform a context switch.  It also complicates the ISR implementation. It appears your code is using method 1.  Line 514 in http://ideone.com/HGLsU vPortPreemptiveTick()  is called in response to tick interrupts, after the task context has been saved.  However, it is declared naked so the compiler will not generate any prologue or epilogue code for it, and it does not include any explicitly itself.  The function will be entered, but execution will just run off the end of the function without attempting to return.  Remove the naked attribute. Conversely, vPortYieldProcessor()  is jumped to directly from the vector table, before any context saving and restoring is performed (goes through the SWI rather than IRQ).  It is declared naked, BUT uses the portSAVE/RESTORE_CONTEXT() macros to perform the necessary prologue and epilogue entry and exit routines. Maybe not everything, but at least something to start off with. Regards.

ARM7 STR71x Rowley port

Ok, the difference betweend the two mode and the nake use is a bit more clear now. Thanks. I had to define ORIGINAL_INTERRUPT_SCHEME in the preprocessor definition to be sure to use the method 1)
And I also removed the naked attribute, but it didn’t help. After a run, the execution thread always and to 0x00000000 which branch to 0x00000000 … I will continue to compare with the STR71x IAR port to see if I did something stupid there. But for know the flu just will keep me aways from keyboard for some time :-(
Will try to dig again this weekend. Thanks for the hints! And if you have good literature that address this kind of thing to recommand I am more than interested :-) Regards, Q.

ARM7 STR71x Rowley port

Hi again, I am not exactly sure of what I did, but it seem to work now. I am able to blink two led at different interval from two task !!
/me happy :-)
Thanks for the help. I will try to clean a bit and to make all the test thread to work, and then I will send it as unsupported port. Q.

ARM7 STR71x Rowley port

Oups, seem that I have spoken to fast… What work :
I am able to run a vLEDTask() that blink correctly a led.
I have tested this with configUSE_PREEMPTION set to 1 and 0.
So I assume that the tick ISR port and stack initialization for this environment/chip is ok now. If I add the IntegerMath task and PollQueue task (common/minimal) it work also (led blink), but only if configUSE_PREEMPTION is set to 1. What don’t work:
If I set configUSE_PREEMPTION to 0 and I leave only the IntegerMath task, it ends in the   
undef_handler loop.
If I add the PollQueue task, it ends in the dabort_handler. If I set configUSE_PREEMPTION to 1 everything run again, but if I add the SemaphoreTasks, it run, but only for 5-6 seconds before ending in pabort_hanlder loop. I don’t know what to deduct from all that, but I suspect that the yield mechanism is not working as it should. Does someone with more intrinsic knowledge of freeRTOS have an idea where to look to solve theses issues? Again thanks in advance… Quentin