# Cortex-A9 port cause FreeRTOS\_Undefined exception **URL:** \ **Category:** Kernel\ **Created:** [November 23, 2018, 6:48pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543 "2018-11-23T18:48:36Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 23, 2018, 6:48pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/1 "2018-11-23T18:48:36Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Friday, November 23, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96): I’m using FreeRTOS 10, with Xilinx’s Zynq 7000 Chip. This is running Linux on core 0 and FreeRTOS on core 1. When apply load to core 1, FreeRTOS will eventually crash to the FreeRTOS\_Undefined exception handler. This is the stack trace: ```auto MyFreeRTOSApp Thread #1 57005 (Suspended : Breakpoint) FreeRTOS_Undefined() at port_asm_vectors.S:96 0x30000040 0x10101018 ``` R14\_und is 0x10101018, this looks like the contents of the stack (R10) as set in port.c How can i figure out what causes this exception? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 23, 2018, 6:57pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/2 "2018-11-23T18:57:47Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, November 23, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/bfaa): Do you know which instruction generated the fault (that is, the value of the program counter at the time the fault occurred)? It should be obtainable from within the exception handler. I have example of how to obtain the offending PC for Cortex-M code, but can’t recall how to do it for Cortex-A. Other than that - have you looked through the list of usual suspects here: [https://www.freertos.org/FAQHelp.html](https://www.freertos.org/FAQHelp.html) Pay particular attention to the interrupt priority requirements. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 23, 2018, 7:10pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/3 "2018-11-23T19:10:03Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Friday, November 23, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/bfaa/117b): Yes, the PC was 0x10101014 at the time the fault occured. This is way outside the valid program space which is 0x30000000 - 0x3800000. I’ve read through the general FAQ and the Cortex-A specific article. 0x10101014 is 1 word above 0x10101010 which is initialized in port.c. If i change 0x10101010 to for instance 0x12301010 in port.c, this will be reflected in the crash, where PC is now 0x12301014. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 23, 2018, 7:17pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/4 "2018-11-23T19:17:58Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, November 23, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/bfaa/117b/831a): Right - agree that value almost certainly must have come from an initialised register value - looks like it has been used to hold a byte, hence the rest of the register is untouched. This could be a stack issue then, where returning from a function or interrupt, etc. has resulted in the wrong value being popped into the PC (by which I really mean, the address used to pop the PC was wrong as the stack pointer was wrong or stack corrupted). I think the first thing to do is check which task was running at the time, assuming it was a task, not an interrupt. You can do that by adding “(tskTCB\*)pxCurrentTCB” to the expressions window in the debugger - that should then decode pxCurrentTCB as a task control block structure that can be expanded to see the task’s name as a string. Alternatively, if you store the handles of the tasks you create, the value of pxCurrentTCB will equal the task’s handle. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 23, 2018, 7:25pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/5 "2018-11-23T19:25:13Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Friday, November 23, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/bfaa/117b/831a/4600): That was the idle task running. Does that mean it has to be an interrupt? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 23, 2018, 7:37pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/6 "2018-11-23T19:37:51Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, November 23, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/bfaa/117b/831a/4600/d71f): I wouldn’t say it ‘has’ to be an interrupt, but would agree it is very likely to be an interrupt. Unless you application has added any functionality to the idle task through an idle task hook function or a trace macro? ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 23, 2018, 8:51pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/7 "2018-11-23T20:51:56Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Friday, November 23, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/bfaa/117b/831a/4600/d71f/8818): No functionality has been added to the idle task. I’ve only installed one interrupt handler on top of what the FreeRTOS port does (the tick handler). The interrupt handler is related to OpenAMP, used to communicate to the other core. I’m not sure how to procede the debugging now, maybe you can give some tips? ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 25, 2018, 4:29pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/8 "2018-11-25T16:29:45Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Sunday, November 25, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/6d00): After some more investigation I found out the stack trace changes when I disable optimizations. The stack trace now becomes this: ```auto Thread #1 57005 (Suspended : Signal : SIGTRAP:Trace/breakpoint trap) FreeRTOS_Undefined() at port_asm_vectors.S:96 0x30000040 ucHeap() at 0x31400994 ``` I also found that the line causing the problem is in tasks.c. The macro traceTASK\_CREATE( ) in the function prvAddNewTaskToReadyList() is defined by Tracealyzer, and it contains calls to portSET\_INTERRUPT\_MASK\_FROM\_ISR() and portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR(). If I remove the portSET\_INTERRUPT\_MASK\_FROM\_ISR() and portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR() calls, everything works ok. If I don’t use Tracealyzer, I can mimic the same behaviour by adding ```auto uint32_t irq_status = portSET_INTERRUPT_MASK_FROM_ISR(); portCLEAR_INTERRUPT_MASK_FROM_ISR(irq_status); ``` or ```auto portDISABLE_INTERRUPTS(); portENABLE_INTERRUPTS(); ``` after the traceTASK\_CREATE() call. It will execute around 1000 -2000 times before it crashes. What can be the issue here? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 25, 2018, 5:56pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/9 "2018-11-25T17:56:58Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Sunday, November 25, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/6d00/f9c6): Are you saying the problem is in the trace macro? So if you remove the trace macros altogether (by not defining them, which makes them take their default empty implementation) everything runs ok? ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 25, 2018, 10:25pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/10 "2018-11-25T22:25:38Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Sunday, November 25, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#cb96/6d00/f9c6/76f2): Yes, that is correct. Will you consider it to be an issue if the trace macro calls portSET\_INTERRUPT\_MASK\_FROM\_ISR() and portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR()? ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 25, 2018, 10:38pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/11 "2018-11-25T22:38:18Z")
**[richarddamon](https://sourceforge.net/u/richarddamon/)** wrote on [Sunday, November 25, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#8a43): One big thing I see here is that …FROM\_ISR stuff is supposed to be called from inside an ISR, while the traceTASK\_CREATE isn’t going to be called from an ISR, but from a task context, so the definition in that macro sounds incorrect. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 26, 2018, 3:49pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/12 "2018-11-26T15:49:37Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Monday, November 26, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#8a43/7e87): If I disable Tracealyzer completely, and instead insert ```auto portENTER_CRITICAL(); portEXIT_CRITICAL(); ``` right after the traceTASK\_SWITCHED\_IN() call, this will result in the same behaviour, the system crashes. It will execute a few thousand times before it crashes. Should the system behave ok when doing this, or is it expected to crash? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 26, 2018, 4:20pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/13 "2018-11-26T16:20:41Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, November 26, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#8a43/7e87/cf7e): I would expect that to crash. traceTASK\_SWITCHED\_IN() is executed inside an interrupt - and those macros are not interrupt safe. There are two reasons I would not expect that to work properly: First exiting the critical section could result in interrupts becoming enabled in a part of the code where they should be disabled, and second those macros are using a critical nesting count that is part of a task’s context - each task has its own nesting count so using it in the interrupt (which is not a task) doesn’t make sense - especially if you switch tasks before exiting the critical section. In this case is sounds like there could be an issue in the implementation of the trace macro, which is provided by Percepio. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 26, 2018, 4:43pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/14 "2018-11-26T16:43:34Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Monday, November 26, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#8a43/7e87/cf7e/b35c): Would you consider it to be an issue if the trace macro calls portSET\_INTERRUPT\_MASK\_FROM\_ISR() and portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR()? Because disabling those lines in the trace implementation fixes the problem. I just need to figure out if the problem is on my part or Percepio’s. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 26, 2018, 4:51pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/15 "2018-11-26T16:51:27Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, November 26, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#8a43/7e87/cf7e/b35c/141c): Not sure - they will enable global interrupts, but leave the interrupt mask in the correct state, and the kernel only really uses the mask. In that particular place (inside the context switch) they could well be necessary. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 27, 2018, 9:27pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/16 "2018-11-27T21:27:15Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Tuesday, November 27, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#8a43/7e87/cf7e/b35c/141c/d87d): Who can answer this? I’ve replicated the issue on a Xilinx dev board with a “Xilinx lwIP TCP perf” example application, and the latest version of Tracealyzer, so I’m pretty sure my setup is not part of the problem. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 28, 2018, 1:34am UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/17 "2018-11-28T01:34:00Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, November 28, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#8a43/7e87/cf7e/b35c/141c/d87d/8bcc): If I recall correctly our last exchange on this was suggesting an issue in the implementation of the trace macros, which are provided by Percepio - so you could ask Percepio - they generally have response support. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [December 4, 2018, 6:04pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/18 "2018-12-04T18:04:19Z")
**[ldb](https://sourceforge.net/u/ldb/)** wrote on [Tuesday, December 04, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#b3f0): Not sure if it is related but I had something similar on the Raspberry PI with preemptive tasking for a very interesting reason. The trace functions are C code and when you call C code on the ARM abi the stack had to be 8 byte aligned even though the normal alignment for a local variable push etc is only 4. This means you can randomly come into the interrupt with the stack in an align 4 position. So check the stack alignment restrictions on your system as this seems to be common with ARM. I had to make sure I aligned the stack up before calling out to c code … failing to do so would randomly crash some time later. So my Irq handler ended up looked like this ```auto /* Save the current context */ portSAVE_CONTEXT /* the stack pointer is 4-byte aligned at all times, but it must be 8-byte aligned */ /* to call external C code */ mov r1, sp and r1, r1, #0x7 ;@ Ensure 8-byte stack alignment sub sp, sp, r1 ;@ adjust stack as necessary push {r1, lr} ;@ Store adjustment and LR_svc bl irqHandler ;@ Call irqhandler /* Reverse out 8 byte padding from above */ pop {r1, lr} ;@ Restore LR_svc add sp, sp, r1 ;@ Un-adjust stack /* restore context which includes a return from interrupt */ portRESTORE_CONTEXT ``` ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [December 12, 2018, 4:14pm UTC](https://forums.freertos.org/t/cortex-a9-port-cause-freertos-undefined-exception/7543/19 "2018-12-12T16:14:41Z")
**[supergaute](https://sourceforge.net/u/supergaute/)** wrote on [Wednesday, December 12, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/dd88c3d250/#b3f0/1222): Was this on the Cortex-A7 or the Cortex-A53 version of the Raspberry Pi? Were you using this with FreeRTOS?