stephman wrote on Wednesday, May 02, 2012:
ah yes, emptying the cache has solved the problem.
Sorry for the convenience.
Regards
Stephane
stephman wrote on Thursday, May 03, 2012:
hi again.
I’ve set a simple project with a blinking led… which does not !
The timer interrupts (RTC) is working fine; but the code does never go into my task.
Here is how I’ve created my task
void main(void) {
EnableInterrupts; /* enable interrupts */
/* include your code here */
prvSetupHardware();
xTaskCreate( led1Task, (const signed char *)"T1", configMINIMAL_STACK_SIZE, NULL, (tskIDLE_PRIORITY ), NULL );
/* Start the scheduler. */
vTaskStartScheduler();
/* Will only get here if there was insufficient memory to create the idle
task. */
for( ;; )
{
}
}
and this is my FreeRTOSconfig.h :
#define configUSE_PREEMPTION 1
#define configUSE_IDLE_HOOK 1
#define configUSE_TICK_HOOK 0
#define configCPU_CLOCK_HZ 50000000UL
#define configTICK_RATE_HZ ( ( portTickType ) 100 )
#define configMINIMAL_STACK_SIZE ( ( unsigned short ) 200 )
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 13 * 1024 ) )
#define configMAX_TASK_NAME_LEN ( 12 )
#define configUSE_TRACE_FACILITY 0
#define configUSE_16_BIT_TICKS 0
#define configIDLE_SHOULD_YIELD 1
#define configUSE_CO_ROUTINES 0
#define configUSE_MUTEXES 1
#define configCHECK_FOR_STACK_OVERFLOW 0
#define configGENERATE_RUN_TIME_STATS 0
#define configUSE_RECURSIVE_MUTEXES 1
#define configQUEUE_REGISTRY_SIZE 0
#define configUSE_COUNTING_SEMAPHORES 0
#define configMAX_PRIORITIES ( ( unsigned portBASE_TYPE ) 6 )
#define configMAX_CO_ROUTINE_PRIORITIES ( 2 )
/* Set the following definitions to 1 to include the API function, or zero
to exclude the API function. */
#define INCLUDE_vTaskPrioritySet 1
#define INCLUDE_uxTaskPriorityGet 1
#define INCLUDE_vTaskDelete 1
#define INCLUDE_vTaskCleanUpResources 0
#define INCLUDE_vTaskSuspend 1
#define INCLUDE_vTaskDelayUntil 1
#define INCLUDE_vTaskDelay 1
#define INCLUDE_uxTaskGetStackHighWaterMark 1
/* It is not advisable to change these values on a Coldfire V1 core. */
#define configKERNEL_INTERRUPT_PRIORITY 1
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 7
Any idea of what I’ve made wrong ?
Thanks
Stephane
stephman wrote on Thursday, May 03, 2012:
which sounds like to be the same problem I had with the DEMO project……
Stephane
stephman wrote on Thursday, May 03, 2012:
I could make FreeRTOS version 4.7 working with the same tasks creation. So the problem with v7 seems to be in configuration or whatever….
Stephane
stephman wrote on Thursday, May 03, 2012:
When I look a t the difference, I can see that the port.c became port.c + portasm.s
One major difference in operation is that in the v7.1.0, the code never stops on Yield interrupt defined in portasm.s
/* Yield interrupt. */
_vPortYieldISR:
vPortYieldISR:
portSAVE_CONTEXT
jsr _vPortYieldHandler
portRESTORE_CONTEXT
I notice that in the V4.7, the VectorNumber was :
interrupt VectorNumber_Vtrap15 vPortYield( void )
wereas this is in V7.1.0
asm void interrupt VectorNumber_VL1swi vPortYieldISR( void );/code]
How is called this VL1swi interrupt (which is in my case never called) ?
I tried to replace by Vtrap15 without success...
Stephanestephman wrote on Friday, May 04, 2012:
Further investigations shown that
the interrupt VL1swi (#109) is correctly raised but for some reasons the code doesn’t jump to the interrupt routine which is in portasm.c
If I write it in the port.c then it’s correctly redirected to this part of the code so the problem is that the portasm.s interrupt routine is not seen by the linker !
/* Yield interrupt. */
_vPortYieldISR:
vPortYieldISR:
portSAVE_CONTEXT
jsr _vPortYieldHandler
portRESTORE_CONTEXT
whereas in port.c there is this line :
asm void interrupt VectorNumber_VL1swi vPortYieldISR( void );
Any idea ?
Thanks
Stephane
stephman wrote on Monday, May 07, 2012:
Well, still stuck with this problem.
Apparently this not directly FreeRTOS linked as this is something related to Codewarrior compiler.
However from what I’m understanding, there is no chance that the FreeRTOS demo project fpr MCF51CN128 can run as long as it uses this ISR in ASM.
A workaround is to come back to port files as it was before FreeRTOS 5.0, meaning without ASM file !
That would work for sure, but I don’t understand why it doesn’t work and if there is a chance to make it working like it is.
If someone has achieved to do that or to run this demo project then please let me know……
Thanks
Regards
Stephane
rtel wrote on Monday, May 07, 2012:
Apparently this not directly FreeRTOS linked as this is something related to Codewarrior compiler.
However from what I’m understanding, there is no chance that the FreeRTOS demo project fpr MCF51CN128 can run as long as it uses this ISR in ASM.
A workaround is to come back to port files as it was before FreeRTOS 5.0, meaning without ASM file !
I don’t understand this. Where has the information come from?
Regards.
stephman wrote on Monday, May 07, 2012:
Hi,
In version 4.7 of FreeRTOS, the Coldfire port wasn’t using this portasm.s file. There was only a port.c and portmacro.h from what I’m seeing.
As said at the beginning of that post, this project using this older version of FreeRTOS was running correctly here.
I’ve spent the last days trying to figure out how to make my simple project working and haven’t seen a piece of code on the web using ASM ISRs with in combination with the Freescale exception.c file.
People are usually ever removing the Freescale exception.c and replacing by a new vector.c file where declarations are made differently like this is done in the Processor Expert component from Erich Styger (who helped me a lot) or using ISR only in C files….
BTW, the project created using Erich’s components works fine.
I absolutely don’t want to tell that this not possible (and I’m quite sure this might possible), but that it seems unusual and that I’ve not found an example showing an ISR in ASM from the Codewarrior wizard project (with exception.c)
Thus, it seems that for the demo project as well as for my simple blinking project which are made using this exception.c file, the code for some reasons can’t jump into the ASM ISR… There is probably something to add or modify in declarations or whatever but I can’t find what.
I’ve posted on freescale’s forum as well regarding this specific problem but I had no answer which could point on the problem and a possible solution.
Now the newest FreeRTOS version (it seems that the change has occured after 4.7 and before 5.0) is using the vPortYieldISR in ASM but for some reasons the linker is unable ever from the demo project as well as from a project from scrap to jump into this ASM routine without modyfing something else.
Do you know if the demo project has been tested by someone like it is right now ?
I hope I’ve not made you upset with my comment. I really think FreeRTOS is a great piece of code and I do appreciate all the support you are providing… for free
I’m just frustrated to not understand what happens 
Best regards
Stephane
stephman wrote on Friday, May 11, 2012:
Hi there
I could make my Simple project working by modifying the exception.c file in a way I don’t really understand :
I had to change the name of the function in the vector list and replace asm_exception_handler by the vPortYieldISR
…
__declspec(weak) vectorTableEntryType vector_107 @VL3swi = asm_exception_handler;
__declspec(weak) vectorTableEntryType vector_108 @VL2swi = asm_exception_handler;
__declspec(weak) vectorTableEntryType vector_109 @VL1swi = vPortYieldISR;
__declspec(weak) vectorTableEntryType vector_110 @Viic1 = asm_exception_handler;
__declspec(weak) vectorTableEntryType vector_111 @Viic2 = asm_exception_handler;
…
and add the following prototype decalaration at the begining of the file :
** extern asm void interrupt VectorNumber_VL1swi vPortYieldISR (void);**
It’s sounds however strange that ;
1. It could link without error whereas this was not working before this modification
2. I have to customize the exception.c file whereas I thought this was a file to never modify and that there is no need to modify this file for ISR which are in C files as I do usually
At least, meanwhile I get further explanation on that, I can go ahead….
Regarding the demo project for MCF51CN128, this can’t be compiled for two reasons :
1. As already mentionned, Codewarrior for some reasons seems to include all sub-directories in its paths and when a file with same name is in several subdirectories, it takes the first one (for instance portable files). This means you have to make a special distribution in a separate directory than the FreeRTOS distrubution and to copy only the needed files (FreeRTOS kernel + includes + portables files + memory file)
2. It seems there is no partest.h file in any subdirectories of that project apparently and which is however included in partest.c. So it seems there is at least one missing file…
If someone has modified this project to let it working I would be interested
Regards
Stephane