I’m running FreeRTOS V8.2.1 on a Texas Instruments CC2835, using IAR 8.20.
I have a project running the same configuration fine, but the associated unit test project crashes at runtime.
I have a Imprecise data access leading to an hard fault. With the debugger I was able to see an unaligned access when the uxListRemove() function is called by prvProcessExpiredTimer(), the value of pxItemToRemove is 0x000013C1.
Thanks to the call stack, I know this occurs in the context of the prvTimerTask. In this project, I only have 3 tasks: IDLE, TmrSvc and my task running unit tests.
Does someone have an idea on how to continue the debugging because I facing a wall right now.
Don’t hesitate if you need more details.
What core does a CC2835 have? I can’t find that part number. From the
description of the problem I’m guessing it’s a Cortex-M.
What is the vaue of pxItemToRemove meand to be? is it just that the
last bit has got set?
As a starting point I would recommend updating the FreeRTOS source files
to V10 and ensure configASSERT() is defined to something that will halt
the processor so you know it is called. Every version of FreeRTOS has
additional configASSERT() calls to help catch misconfigurations.
I don’t think the expected value of the pxItemToRemove pointer would be the same as previously without the last bit set (when I try to modifiy this value I have a bus fault on an instruction prefetch).
Could it be related to the configUSE_TICKLESS_IDLE option (which, by the way, is set in my project - but I tried without it and I have the same behavior).
To me, upgrading to FreeRTOS V10 would be the last option, uour firmware is part of a medical device and the update would generate a non negligible amount of work related to our quality system.
Would it be worth it to upgrade the FreeRTOS source to V8.2.3 to you ?
I decided to upgrade the source of FreeRTOS to v8.2.3, some additionnal configAssert() are defined and were useful to detect an unitialized timer caused the Hard Fault described above.
POst script - seems you have found the problem. funny my system didnt show it.
however left here for utility…
Suggest using GCC align directives to align up the problematic structures. avoid packing unless you have some IO interface.
Though I thought M3/M4 only had a problem with unaligned access on FP ?
something to go on:
If you have external memory, unaligned accesses are often not allowed .
Unaligned access that cross memory regions are trouble,
Unaligned access into bitbanded regions are trouble,
and this gem in the M3 book
"
All Cortex-M3 external accesses are aligned.
Unaligned support is only available for load/store singles (LDR, STR). Load/store double already supports word aligned accesses, but does not permit other unaligned accesses, and generates a fault if this is attempted"
Have a look what code the compiler is generating. to my knowledge GCC is aware of these problems. I have NEVER seen it a problem. I use Rowley tools.
My apologies if I am teaching you to suck eggs, but as your are time poor , thought I would chip in. glen