Hi!
I have also run into a bit of a small bug/snag with the latest (v.1.187 with the line in the.drvfile changed) freertos running on CW6.3.1 ad PE 3.09
Warning : L1016: File C:\Git\elux\CBTconverter\CBTconverter_Data\Standard\ObjectCode\heap.c.o found twiceCBTconverter.prm line 24
It is only a warning, but i guess that it should not be inserted twice.
Best regards
Martin
Hello,
linking the heap module twice is definitiely not a good sign.
Maybe clearing the Generated_Code folder inside the project should help, otherwise it would be good to find out why the heap module is present twice?
BK
I have manually deleted the contents in CODE that i have not edited. I also removed the TROSSWI1.c and RTOSTICK1.c but they appear again when rebuild. Also, when i look in linkorder, it has heap listed more then once. If i remove it from the linking, it will appear in the list when i hit make.
Any clues of where i should look?
// Martin
Hello,
the SWI and the TICK modules are required (they are for the context switch and the tick timer).
I'm using the eclipse version of CodeWarrior, but I see if I can reproduce what you report with V6.3.
BK
Strage.
If i choose to preprocess the files in the "link order" tab i see that the have quite diffrent path
C:\Git\elux\CBTconverter\CODE\heap.c'
and
C:\Program\Freescale\CodeWarrior for Microcontrollers V6.3\lib\hc08c\src\heap.c
These are definently not the same. The latter one only contains a _heapcrash_ function
Very strange.
// Martin
Hello,
the one from
C:\Git\elux\CBTconverter\CODE\heap.c'
is the one from FreeRTOS.
The one from
C:\Program\Freescale\CodeWarrior for Microcontrollers V6.3\lib\hc08c\src\heap.c
is the one from the ANSI library.
Usually heap.c is part of the ansiis.lib (the name depends based on the selected memory/floating point options).
Attached is a screenshot of my link order tab, and this works ok for me. Maybe you can spot a difference?
BK
thinking a little bit more about this problem: maybe you use malloc() somewhere else? Then the linker will link against the malloc() from the heap.c from the ANSI library as well. This would explain the problem you are seeing.
Could you check this (in the .map file)?
Additionally, you might change the link order (in the link order tab) and move the anis*.lib to the end of the list?
BK
Hello,
I quickly tried it with a CW 6.3 (screenshot attached): I only have one heap.c (which is correct). Additionally I have attached my quick-and-dirty project.
I'm wondering what your problem could be.
Maybe you could provide your project and I'll have a look.
BK
Hi!
normally, i could never attach a project, but since this is so extremy early then it littraly dont do anything but blink some diodes and print on the uarts. I run it on a DEMO9S08AC60 board.
Im a starting to guess that i have a includepath that does not quite do what it should. All my installations of CW and PE are quite fresh, but nevertheless there seems to be something strange.
// Martin
nevermind.
Once i removed the bad heap.c from the linklist i worked fine. Very strange. removing both just reintroduced the problem again
BTW. i noticed that the port.c file appears to be from FreeRTOS 6.0.5 still. It does atleast say so in the header.
// Martin
thanks for the note about the port.c: I have fixed the comment about the wrong version number.
I'm working anyway on porting the new V7.1.0 in the next days or so (as much time permits).
BK
Hi!
For kicks, I updated my project to use v7.1.0 of freertos. I took version 1.189 of BlackNights website. I also updated Utility to version 1.080.
Afterwards, i get these errors
+FRTOS1 +INTERNAL ERROR: at line 21: Unknown soubroutine: RTOSAdap_defineRTOSFunction (file: Drivers\sw\FreeRTOS.ts2) +INTERNAL ERROR: at line 20: Unknown soubroutine: RTOSAdap_defineRTOSFunction (file: Drivers\sw\FreeRTOS.ts2) +INTERNAL ERROR: at line 18: Unknown soubroutine: RTOSAdap_defineRTOSFunction (file: Drivers\sw\FreeRTOS.ts2) +INTERNAL ERROR: at line 17: Unknown soubroutine: RTOSAdap_defineRTOSFunction (file: Drivers\sw\FreeRTOS.ts2)+FRTOS1 +ERROR: There are errors in component, it is impossible to generate code
I am using CW 6.31 with PE 3.09
I also noticed that the line in FreeRTOS.drv had changed back to be uncommented out. However, commenting it out dit not resolve anything.
Any clues?
Best regards
Martin
1.189Hello,
MCU10.x has introduced the concept of RTOS adapters. This does not exist in MCU6.3 and causes the problem you see.
Looks like I might need to release two versions of the component: one for MCU10/eclipse and one for MCU6.x.
Here is how you can disable the RTOS adapter thing (plus another issue with the older Processor Expert):
a) In
C:\ProgramData\Processor Expert\CW08_PE3_09\Beans\FreeRTOS\FreeRTOS.bean
search for following line and remove it:
<OperatingSystemId>FreeRTOS</OperatingSystemId>
b) In
C:\ProgramData\Processor Expert\CW08_PE3_09\Drivers\sw\FreeRTOS.drv
remove following line (or comment it out with '%-':
%include sw\RTOSAdaptor\FreeRTOS_RTOSAdaptor.prg
Additionally, change
%if (defined(RuntimeCntr) & defined(@RuntimeCntrLDD@OnCounterRestart)) | (defined(RuntimeCntrLDD) & defined(@RuntimeCntrLDD@OnCounterRestart))
dword %'ModuleName'%.RunTimeCounter; /* runtime counter, used for configGENERATE_RUNTIME_STATS */
%endif
into
%if defined(RuntimeCntr) & defined(@RuntimeCntrLDD@OnCounterRestart)
dword %'ModuleName'%.RunTimeCounter; /* runtime counter, used for configGENERATE_RUNTIME_STATS */
%elif defined(RuntimeCntrLDD) & defined(@RuntimeCntrLDD@OnCounterRestart)
dword %'ModuleName'%.RunTimeCounter; /* runtime counter, used for configGENERATE_RUNTIME_STATS */
%endif
c) In
C:\ProgramData\Processor Expert\CW08_PE3_09\Drivers\sw\FreeRTOS.ts2
remove the content (make empty file or comment everything with '%-'
I have attached the changed version of the component so it should work now as well for the old 6.3.
BK
Hello,
there is now a new FreeRTOS port (which includes as well S12 and S12X) available. See
http://mcuoneclipse.wordpress.com/2012/02/11/back-to-classic-freertos-for-freescale-s12x/
This Processor Expert component works now as well for non-eclipse CodeWarrior: you need to set the component property 'Classic CodeWarrior' to yes as outlined in the blog.
I have verified that this works both with CodeWarrior for MCU 6.3 and CodeWarrior for S12(X) 5.1.
Hope this helps,
BK
Dear All,
Thanks for all the reply, I've changed the controller type to DZ32 in the example test_rtos posted by BN and put the same linkage order and rtos settings (which were the same), now it works fine. I'll explore more things ...
I've tried also on qb8 but there is not enough ram, I'll try helium.
Thanks for all the help
Best regards and happy new year from fran ce
fran cois
Hello,
ok, that project helps :smileyhappy:.
And indeed there are a few problems with that project.
- somehow your project file has a problem: I get 'Rescued Items' with a heap.c
- the result is that there were two heap.c in the Link Order tab: removing the rescued item fixed this too.
After that, everyhing seemed to be ok (at least linking properly).
I have attached the fixed .mcp file: close your project (or exit CodeWarrior), replace your current .mcp with the new one, and you should be up and running again.
Hope this helps,
BK
I have upgrade FreeRTOS bean to version 1.187, but when generate code by PE, it said:
+INTERNAL ERROR: at line 13: error in including "Drivers\Sw\RTOSAdaptor\Common_RTOSAdaptor.prg"
(file: Drivers\sw\RTOSAdaptor\FreeRTOS_RTOSAdaptor.prg)
and I can't find Common_RTOSAdaptor.prg any where.
use:
Codewarrior V6.3,
PE V3.09,
CPU: HCS08
Cai.
Hello,
thanks for reporting. This is indeed a problem (I used the eclipse version of CodeWarrior).
What you can do is to open this file
C:\ProgramData\Processor Expert\CW08_PE3_09\Drivers\sw\FreeRTOS.drv
(I'm using Windows 7, so your path might be different)
and on line 74 add a %- in front of the line to comment it out:
%- %include sw\RTOSAdaptor\FreeRTOS_RTOSAdaptor.prg
And I have uploaded/published a new version (v1.188) which has the fix too.
BK
What is affected by the ColdFire V1 CPU setting in the FreeRTOS component?
Does it only control the INTC Set Interrupt Force Register (INTC_SFRC) assignment
in portYIELD()?
I'd like to try it on an MCF51AC256 which isn't in the supported CPU list.
MCF51AC has the same INTC_SFRC definition as the MCF51QE.
Can I just tell the component I'm using an MCF51QE?
Bill