Quality RTOS & Embedded Software

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




Loading

IAR Cortex R4F Port - Some Comments

Posted by westmorelandeng on March 16, 2015

Hello Richard,

Just a few comments regarding what I've seen thus far getting the port to run on the TI Cortex R4F Family with the latest IAR tools:

*) I had to do a slight fix-up on the LR register to make sure it was calculating its offset from the tasks' stack frame. It seems to work and was the only way I was able to get around a prefetch abort vector error I was getting. I wasn't quite sure why that offset was 8 bytes from the bottom (or maybe the top, depending on how you look at it) of the tasks' stack in the instruction that does the #+60. I 'emulated' that - meaning I did a fix up to make sure the behavior matched the existing port under CCS (6.x). I thought just doing the calculation without the 8 bytes difference was OK too - meaning at the first word in the stack being the demarcation of the fix-up - which seemed to work OK too - but I am running with the 8 offset now (calculation comes out to 56 bytes right now I think).

*) I had configUSETICKHOOK defined with an empty tick hook handler - xTickCount counted to 1 and then the uxPendedTicks happily ticked away as if it was xTickCount. Not sure if that is the intended operation or not when the handler is empty but just wanted to mention that.

I'm not sure just yet if this port is 100% stable at this point; seems to be running but I would like to test it for awhile.

Thanks and Regards, John W.


IAR Cortex R4F Port - Some Comments

Posted by rtel on March 16, 2015

HI John - was I aware you were doing this work. If so, apologies, I had forgotten. I have recently produced a GCC port for the Cortex-R devices. That is not published yet, but was basically the same as the port for Cortex-A devices.

Regards.


IAR Cortex R4F Port - Some Comments

Posted by westmorelandeng on March 16, 2015

Richard,

No - now that I reread that - I understand why you may have taken it that way. Sorry about that - just meant I want to run the port for a while. Are you working on the IAR port then?

Wanted to mention a few other things - I used heap5.c to 'isolate' what the tools wanted to do with the memory (and stacks) vs. the RTOS. I found that to be pretty convenient actually and not really the original intention of that - but really useful.

I also looked at the HALCOGEN tool v4.03.00 - didn't realize it had evolved that much but I did try to make a few quick ports using that and didn't really have a lot of luck - I was quickly back to the prefetch abort error. I had to do the fix-up; or rather; make sure the calculation for the restoration of LR was done within the tasks' stack boundary. A 'NULL' or invalid value there is somewhat disastrous as you know.

And this was using v8.2.0 of the kernel.

Thanks and Regards, John W.


IAR Cortex R4F Port - Some Comments

Posted by westmorelandeng on March 17, 2015

Richard,

This is interesting - I am doing some debugging; xTickCount isn't incrementing but the Idle task (hook) is running - is that possible?

Maybe a bug on my end, but interesting.

Thanks, John


IAR Cortex R4F Port - Some Comments

Posted by rtel on March 17, 2015

Yes - if the tick count is not running then the higher priority tasks will run uninterrupted until they block on something, allowing a lower priority task to run until it blocks, until finally the idle task is the only task left running - so if the tick interrupt is not firing what you have observed is expected.

Regards.


IAR Cortex R4F Port - Some Comments

Posted by westmorelandeng on March 17, 2015

OK Richard.

Thanks, John


IAR Cortex R4F Port - Some Comments

Posted by westmorelandeng on March 19, 2015

Richard,

Just wanted to mention something - I had to add the following at the end of portRESTORE_CONTEXT to make sure LR got the right address for the task:

	LDR		LR, pxCurrentTCBConst                                   ; make sure LR isn't fubar
            LDR             LR, [LR]
            LDR             LR, [LR]                                                ; dereference pointer
	LDR		LR, [LR, #+0x44]
            DSB
	/* ; And return - correcting the offset in the LR to obtain the */
	/* ; correct address. */
	SUBS PC, LR, #4

; nop endm

  • Port seems to be OK after that - I need to run more tests. Not sure; but I think I may see a priority inversion issue right now - but I need to double check that.

Regards, John


[ 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