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 configUSE_TICK_HOOK 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.
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.
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.
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.
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.