Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Project from scrap. Problems MCF51CN

Posted by Stephane Rey on April 30, 2012
Hi everybody,

I'm trying to implement FreeRTOS for MCF51CN128.

First I've tried the demo project which unfortunately doesn't compile. It sound impossible to compile as this demo intended for Coldfire V1 seems to refer to some MSP430 header files.... I've been unable to make something working with that and it made me more confused again.

So I try to create a project from scrap and this is not straitfoward also.

I've copied the FreeRTOS C files + includes + portable files (port.c + portasm.c + heap_2.c) into my project
I've added the FreeRTOSconfig.h to my sources files
Now when compiling, it gives errors regarding fucntions
- vApplicationTickHook
- vApplicationStackOverflowHook
from task.c which are not refered.
In task.c their prototype is declared as extern.

When looking at the demo project, I see these functions that I don't underestand what it is (not really documented) are defined in the main.c file !

So my questions are:
- Are they part of the FreeRTOS kernel as they are called by task.c ? If so why are they located in main.c ? I don't understand the basic idea behind having a kernel supposed to be portable, with calls to functions declared in a demo project in main.c. How can the user now that it is and how to implement if ?

- Does anyone has achieved to use freeRTOS on MCF51CN128 or to correct the demo project ?

Any help appreciated.
Cheers
Stephane
-

RE: Project from scrap. Problems MCF51CN

Posted by Richard on April 30, 2012
“First I've tried the demo project which unfortunately doesn't compile. ”


I assure you that, when used with the compiler/IDE it was created with, it does compile.

“It sound impossible to compile as this demo intended for Coldfire V1 seems to refer to some MSP430 header files”


Umm, not it doesn't, but I can see why you might come to that conclusion.

I have just spent x hours downloading and installing the extraordinarily massive Eclipse version of the CodeWarrior tools, and was pleased to see it includes an import wizard. I was even more pleased when I saw that it appeared to import the classic IDE project without error. I was less pleased when I realised it only thought it had imported it. When I tried to build it I get the error:

"the file msp430.h cannot be opened".

It says that, because it is not including the correct version of portmacro.h.

Now, looking at the include paths I see that "${CW_Project}\..\..\Source\portable\CodeWarrior\ColdFire_V1" is mentioned, and that is indeed where the correct version of portmacro.h lives, so why it is attempting to use the one from the Source\portable\GCC\msp430 one is a mystery, especially as the project explorer even shows the correct file being used, and right clicking on the header file in the include directive also takes you to the correct place. I think there is some strange dependency scanner issue in the tools (not unusual with Eclipse).

So, I deleted every other copy of portmacro.h (there is one per port), and tried compiling again. Now it is generating an error because it can't find a file that is part of the PIC18 port - so that seems like a good point to give up, but I'm in the mood for a challenge, so...

I deleted all the files related to every other port, created a new workspace, and imported the classic project one more time, and hey presto - it built without any errors or warnings this time. I have no idea if it runs, but it builds.

So, go back to the original, unmodified, V1 project as found in the FreeRTOS download. Then, in the FreeRTOS\source\portable directory, delete every directory other than the following:

FreeRTOS\portable\MemMang
FreeRTOS\portable\CodeWarrior\ColdFire_V1

Then, delete heap_1.c and heap_2.c from FreeRTOS\portable\MemMang, make sure your Ecplise workspace is completely clean of any trace of the first attempt at importing the project (preferably use a new workspace), and finally use the CodeWarrior import wizard to import the original .mcp file again, and you should be all set.


“Now when compiling, it gives errors regarding fucntions
- vApplicationTickHook
- vApplicationStackOverflowHook
from task.c which are not refered.
In task.c their prototype is declared as extern.”


Look up hook functions in the documentation. You either need to configure FreeRTOSConfig.h not to look for these functions, or you need to define them.


“ don't understand the basic idea behind having a kernel supposed to be portable, with calls to functions declared in a demo project in main.c”


These are application definable hook functions (or callback functions, if you prefer). They are not part of the kernel, but allow the application writer to add code into certain kernel events, if they want to.

Regards.

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 1, 2012
Hi,

Many thanks for this long, detailled and valuable answer.

I'm going to try right now to isolate the dedicated files needed for this demo project and compile. I'll let you know.
However I'm using Codewarrior 6.3 "classic version" and it sounds like you had the same behavior with CW 10.2 under Eclispe. This might be then a problem affecting both version. Good to know.

Regarding my question for the two calls to Hook functions, I would say that for someone not knowing FreeRTOS like me and trying to use it for the first time, this would be better to have a demo project very minimalist like just blinking few leds in order to understand the core and how to use it. This is what I'm trying to set.
Then more complex projects could be good when starting to code applications.

But for running FreeRTOS for the first time I would think that a very very simple project showing what are the minimum functions and files to use would be easier and faster to start with, providing then a template frame for new projects. I have to admit that this is quite difficult for me to understand each line/function of the demo project as this is already quite complex.

Moreother, I would probably not reuse a demo project as a start for a new project but I would like to start a new project from scrap in order to include only the files and functions I need. This would definitely not be FMEA compliant otherwise.
The documentation lists the minimum files requested for the kernel and based upon that I've tried to set a project. But Then I face the freeRTOSconfig.h and main.c files which are including much more things than requested to start with in demo projects.

Well, back to Codewarriior and I'll let you know if I can both compile the demo project now and start my new project from scrap by tuning the freeRTOSconfig.h

Thanks again
Stéphane

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 1, 2012
maybe a note should be added in the FreeRTOS distribution in order to mention this problem of paths with codewarrior and that it is mandatory to copy the needed files somewhere else than the FreeRTOS path ?
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Richard on May 1, 2012
“However I'm using Codewarrior 6.3 "classic version"”


That is interesting, because I think the project was originally created with 6.2.2 according to the documentation page for that port. The latest tools are V10.x.

“I would say that for someone not knowing FreeRTOS like me and trying to use it for the first time, this would be better to have a demo project very minimalist like just blinking few leds”


This is feedback which is often received, and why all newer demo projects have to configurations, a simple "Blinky" style demo, and a fully featured demo. The ColdFire demos are relatively old, so pre-date that change though.

There are also these demos too:
http://www.freertos.org/simple-freertos-demos.html

“Moreother, I would probably not reuse a demo project as a start for a new project but I would like to start a new project from scrap in order to include only the files and functions I need.”


It is always recommended to start with an existing project, to save you time, and give a better "out of the box" experience more than anything, but I still understand the point.

The pages that provide the most help are probably:
http://www.freertos.org/FreeRTOS-porting-guide.html
http://www.freertos.org/porting-a-freertos-demo-to-different-hardware.html

Regards.

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 1, 2012
again thanks. I'm going to go deep inside these docs and try to set my simple project for V1.

It seems there is a problem with the FreeRTOS.org website, I can't access anymore to the download page. (even for downloading the package or the simple FreeRTOS demos you pointed me.

Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 1, 2012
ok, I could achieve to compile the demo project erasing everything and only keeping the following directories :
- Demo\ColdFire_MCF51CN128_CodeWarrior
- Demo\Common
- Source\Portable\Codewarrior
- Source\Portable\MemMang

It might be useful to know for the ones who'd like to test this project.

Now I'm going to focus on creating a minimalist project to start with. Then with these two projects It would be easier then to progress in more advanced functions.

Thanks again
Stéphane

RE: Project from scrap. Problems MCF51CN

Posted by Richard on May 1, 2012
“It seems there is a problem with the FreeRTOS.org website, I can't access anymore to the download page. (even for downloading the package or the simple FreeRTOS demos you pointed me.”


The website has been completely updated, and there are some problems with cached pages. Please delete your local cache in your browser, and try again.

You might also be able to trick the browser into loading the page again by adding a query to the end of the URL, for example:

http://www.freertos.org/a00104.html?dummy_string

Regards.

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 1, 2012
well none of them are working. I've just tried from a station where I never wen to FreeRTOS.org and still can't access the download page.
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Richard on May 1, 2012
“well none of them are working”


To help me debug this I would be grateful if you could provide answer to all the following:

What is happening when you try and open the page?

Are you getting a URL like http://www.freertos.org/index.html?http://www.a00104.html?

If you try it now, what happens?

Regards.

RE: Project from scrap. Problems MCF51CN

Posted by Richard on May 1, 2012
The URL in my previous post is wrong, but the concept is write, a URL that goes to index, followed by a ? followed by the URL you want.

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 1, 2012
It sounds like you have modified sometthing. Initially I had an URL like you gave me above.
Now, If I click on the download page, the link is http://www.freertos.org/a00104.html?1
but it still open the page :

"Please support the FreeRTOS project!
The FreeRTOS project has been generated through many years of hard work - but is provided to you here free of charge. Please show your support by buying a book, or simply making a donation. Thank you.
Documentation
...."

RE: Project from scrap. Problems MCF51CN

Posted by Richard on May 1, 2012
“but it still open the page :

"Please support the FreeRTOS project!”


Ah - ok - this is the right page now. The download link is just below that in the section "RTOS Source Code Downloads". I take it that is not what was happening before.

I changed a few things. One was to put the dummy parameter on the end of the URL, and another was to try and catch the old FreeRTOS.org/index?actual_page.html formatted URLs with some javascript to strip off the beginning part.

Anyway, it sounds like it is working now. That is a relief, it was always a risk trying to remove the frames that people would run into this type of issue. Thanks for reporting back.

Regards.

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 2, 2012
Hi,
Well, the demo project compiles but doesn't work.
The code doesn't go into the timer interrupt for the scheduler...

Well, I'm going to start a project from scrap. I'm spending too much time on the demo project without beeing able to make it working.
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Dave on May 2, 2012
Note what was said before about the V2 compiler change causing problems, and the fix. If the demo compiles but does not run have you looked to see if the issue is the same?

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 2, 2012
Hi,

Thanks for answering. However I do not understand your comment on the V2 compiler change ? Is it something discussed in the forum earlier ? I tried a search but found nothing in relation.

Thanks
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Dave on May 2, 2012
See the comment here http://www.freertos.org/a00104.html?1#knownissues

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 2, 2012
Thanks,

Then I don't think this is related as I'm using the classic version of codewarrior 6.3 (not Eclipse based) and V1 core.

Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 2, 2012
Richard,

This link doesn't work : http://www.freertos.org/simple-freertos-demos.html
it jumps very quickly between two URL from my location.
Cheers
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Richard on May 2, 2012
Did you clear your browser cache, as per a previous suggestion when the download page had a problem?

Regards.

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 2, 2012
ah yes, emptying the cache has solved the problem.
Sorry for the convenience.
Regards
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 3, 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_HOOK1
#define configUSE_TICK_HOOK0
#define configCPU_CLOCK_HZ50000000UL
#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_TICKS0
#define configIDLE_SHOULD_YIELD1
#define configUSE_CO_ROUTINES 0
#define configUSE_MUTEXES1
#define configCHECK_FOR_STACK_OVERFLOW 0
#define configGENERATE_RUN_TIME_STATS 0
#define configUSE_RECURSIVE_MUTEXES1
#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_vTaskPrioritySet1
#define INCLUDE_uxTaskPriorityGet1
#define INCLUDE_vTaskDelete1
#define INCLUDE_vTaskCleanUpResources0
#define INCLUDE_vTaskSuspend1
#define INCLUDE_vTaskDelayUntil1
#define INCLUDE_vTaskDelay1
#define INCLUDE_uxTaskGetStackHighWaterMark1

/* 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

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 3, 2012
which sounds like to be the same problem I had with the DEMO project.....
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 3, 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

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 3, 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...

Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 4, 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

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 7, 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

RE: Project from scrap. Problems MCF51CN

Posted by Richard on May 7, 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.

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 7, 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

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on May 11, 2012
up.
Has anyone an idea ?

Thanks
Stephane

RE: Project from scrap. Problems MCF51CN

Posted by Stephane Rey on 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


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS