# Tracking down the cause of an unaligned memory access exception **URL:** \ **Category:** Kernel\ **Created:** [August 1, 2024, 12:45pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084 "2024-08-01T12:45:51Z")\ **Posts on this page:** 17\ **Page:** 2
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [August 7, 2024, 12:27pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/21 "2024-08-07T12:27:59Z")
you do not need the critical section in the isr as the isr will by definition run uninterrupted with respect to the task. You would only need it if there was a higher priority isr attempting to use your data concurrently. ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [August 7, 2024, 1:15pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/22 "2024-08-07T13:15:48Z")
Hi Gaurav - that is a good point which I had forgotten about - thanks. PS: yes, it was a typo, I am talking about `taskENTER_CRITICAL_FROM_ISR` ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [August 7, 2024, 1:16pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/23 "2024-08-07T13:16:43Z")
Hi @RAc - Yes, I take the point, I was being a bit over-cautious… ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [August 7, 2024, 6:09pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/24 "2024-08-07T18:09:38Z")
Hi Gaurav Actually, it looks like my port does not support nested interrupts. I looked in FreeRTOSconfig.h and there are no definitions for `configKERNEL_INTERRUPT_PRIORITY` and similar, and they are not present in the port. So (according to my updated understanding) it makes sense that there are also not definitions for `taskENTER/EXIT_CRITICAL_FROM_ISR`? Ie. there is no problem here… Shame ;-(. Jon N ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [August 7, 2024, 6:45pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/25 "2024-08-07T18:45:27Z")
Even if I am in danger of repeating myself to boredom… one of the best tools to attack your intermittent problem is tracealyzer, the very best one being a deep trace, but not all boards/tool sets/eco system support that. ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [August 7, 2024, 9:25pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/26 "2024-08-07T21:25:30Z")
Thanks … I think I have read about tracealyzer, but do not know much about it. I am investigating … but I fear our setup might be a little too much off the beaten track for them… ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [August 8, 2024, 9:30am UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/27 "2024-08-08T09:30:52Z")
> [@jkn](#): > > We did a bit of tracking down and found that we are getting stuck inside xTaskIncrementTick(). Specifically we can trigger a configASSERT at this point in the FreeRTOS code: One possiblity is that the list item is getting corrupted. You can try to enable [list item integrity checks](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/include/list.h#L146) by setting `configUSE_LIST_DATA_INTEGRITY_CHECK_BYTES` to 1 in your FreeRTOSConfig.h: ```auto #define configUSE_LIST_DATA_INTEGRITY_CHECK_BYTES 1 ``` ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [August 8, 2024, 4:31pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/28 "2024-08-08T16:31:42Z")
Hello Gaurav - hey, that looks really interesting, thanks. I had not come across `configUSE_LIST_ DATA_INTEGRITY_CHECK_BYTES` before, although I see it was introduced … in 2015. It doesn’t seem to be well documented/publicised; is that because it is more intended for your internal use? I will definitely be giving this a try. Thanks, Jon N ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [August 8, 2024, 4:45pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/29 "2024-08-08T16:45:16Z")
Tracealyzer looks interesting … I am trying to determine what effort it might take to get this running on our core. What do you get when _buying_ Tracealyzer? Is it the DLL that you use with a debugger to analyse the uploaded trace buffer? Thanks, jon Thanks, Jon ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [August 9, 2024, 5:45am UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/30 "2024-08-09T05:45:19Z")
> [@jkn](#): > > It doesn’t seem to be well documented/publicised; is that because it is more intended for your internal use? Kind of - it is more for debugging list implementation which is not part of public API. > [@jkn](#): > > What do you get when _buying_ Tracealyzer? Is it the DLL that you use with a debugger to analyse the uploaded trace buffer? It is a PC application which provides a nice UI to visualize trace and understand your application behavior. This page provides more details - [Tracealyzer for FreeRTOS - Percepio FreeRTOS Analyzer for Everyday Use](https://percepio.com/tracealyzer/freertostrace/). ---
**Author:** ![Jessica32](https://avatars.discourse-cdn.com/v4/letter/j/48db29/32.png) [@Jessica32](https://forums.freertos.org/u/Jessica32)\ **Post date:** [August 9, 2024, 5:46am UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/31 "2024-08-09T05:46:55Z")
“Thanks so much for sharing this! It’s really helpful and much appreciated.” ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [November 15, 2024, 1:03pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/32 "2024-11-15T13:03:21Z")
(updated reply with a slightly different slant - we are getting back to investigating this problem after a bit of a break) This is to clarify an observation in our code and port. We have got our FreeRTOS Timer tick set to use the FIRQ interrupt. So (for instance) the interrupt frame is different to a non-FIRQ interrupt. However the actual tick interrupt C function is not declared (eg. via **attribute** (( **fast\_interrupt** )) to match. Am I right in thinking that this might cause issues? I am curious how FreeRTOS ports deal with this configuration possibility in general… Thanks, jon N ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [November 15, 2024, 2:07pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/33 "2024-11-15T14:07:57Z")
First, since the port defines the actual interrupt service routines, it is the port that needs to define things to match what is being done, and if moving the tick interrupt to the FIRQ means a need to change the declaration, the port needs to do that. Second, the interrupt frame being different won’t matter unless that frame is used to store the registers for resuming the task, but for ARM processors, it isn’t that ISR frame, but the frame from the Pend-SV interrupt that occurs after this ISR leaves. If you are doing the scheduling as a called function from inside the ISR, then YOU, as the port writer need to be sure to handle the various cases, and still, that function tends to save all the state and not rely on the ISR register save. ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [November 15, 2024, 2:57pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/34 "2024-11-15T14:57:48Z")
Hi Richard, thanks for your reply: > First, since the port defines the actual interrupt service routines, it is the port that needs to define things to match what is being done, and if moving the tick interrupt to the FIRQ means a need to change the declaration, the port needs to do that. I was partly separating out ‘the port’, which might be agnostic about whether the timer IRQ was an FIRQ or not, and the … ‘application build’, which might choose one way or the other. I don’t know if this is a reasonable thing to tease out in this way… > Second, the interrupt frame being different won’t matter unless that frame is used to store the registers for resuming the task, but for ARM processors, it isn’t that ISR frame, but the frame from the Pend-SV interrupt that occurs after this ISR leaves. I am not thinking on an ARM port FWIW. > If you are doing the scheduling as a called function from inside the ISR, then YOU, as the port writer need to be sure to handle the various cases, and still, that function tends to save all the state and not rely on the ISR register save. Indeed … I have not yet fully bottomed out whether I think this is a real issue for us, but wanted to ask a bit around it in general. Regards, jon N ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [November 15, 2024, 3:50pm UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/35 "2024-11-15T15:50:24Z")
> [@jkn](#): > > I was partly separating out ‘the port’, which might be agnostic about whether the timer IRQ was an FIRQ or not, and the … ‘application build’, which might choose one way or the other. I don’t know if this is a reasonable thing to tease out in this way… The processing of “system” resources are in the “Port” layer, which might define them “weak” so a given application can change them, but then that part of the application is actually becoming the application specific port. As to the mentioning of the ARM port, that was more as to that style of operation. As far as I am familiar, there are basically two ways to handle the task switching, either using an interrupt that will be delayed until any interrupt that is currently running has returned, and that ISR saves all the current processor state, changes current task (by calling the scheduler) and then restores the current processor state for the newly chosen processor. The other method, if such an interrupt isn’t available, is to call a function that does that processor state save, schedule, and the restore the state, but then you need to handle the fact that the ISR that calls that function, and any ISRs it has nested with, will not complete until that switched out task get resumed. That means this sort of operation needs to either disallow nesting of interrupts, or any interrupt that happens needs overhead to keep track of interrupt nesting and at the very end, see if someone (maybe not itself, but something that nested inside it) requested a rescheduling. If this is the way this port is working, using the FIRQ automatically means nesting is possible, so that needs to be handled. If the original port assumed no nesting, then you will have problems. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [November 18, 2024, 5:15am UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/36 "2024-11-18T05:15:14Z")
> [@jkn](#): > > We have got our FreeRTOS Timer tick set to use the FIRQ interrupt. So (for instance) the interrupt frame is different to a non-FIRQ interrupt. > > However the actual tick interrupt C function is not declared (eg. via **attribute** (( **fast\_interrupt** )) to match. Which port are you using? Did you write a FIQ handler which saves the required registers before clobbering them? Just for a quick test, can you change the tick to IRQ and see if the problem goes away? ---
**Author:** ![jkn](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@jkn](https://forums.freertos.org/u/jkn)\ **Post date:** [November 18, 2024, 8:43am UTC](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084/37 "2024-11-18T08:43:15Z")
Hi Gaurav Yes, we are trying using the tick in a non-FIRQ manner at the moment. I am just trying to examine around the subject, as it were - I would like to be clear about the situation as well as making empirical observations. Regards, Jon N [Previous page](https://forums.freertos.org/t/tracking-down-the-cause-of-an-unaligned-memory-access-exception/21084.md?page=1)