I am using a TI processor so I have generated the driver code with their HAL generation tool which is also where I got the FreeRTOS source files. How do I check the ISR priorities?
Safest way is from the nvic registers, but your configuration tool must provide some way to configure that manually. I do not know your tool set, so you will need to figure that out yourself, sorryā¦
No worries, I am using the following interrupts at the moment:
esmHighInterrupt on channel 0 (IRQ)
phantomInterrupt on channel 1 (IRQ)
rtiCompare1Interrupt on channel 3 (IRQ)
gioHighLevelInterrupt on channel 9 (FIQ)
linHighLevelInterrupt on channel 13 (IRQ)
vPortYeildWithinAPI on channel 21 (IRQ)
According to TIs technical reference manual for this processor the lowest numbered channel is given the highest priority.
I have attached the sys_vim.c file here, Iām not sure if it would be helpful or not.
sys_vim.c (36.3 KB)
so in your mcu, channels nd priorities are equal? If so, we still need to know what the max syscall priority is set to. it may be in the freertosconfig default file, but it does not look like a sound practice to not define it explicitly. That identifier is essential to correct FreeRTOS operation.
It seems that way based on what the documentation says.
I donāt think its set at all. There is no mention of it in any of the project files.
I suppose the big question is what Interrupt Controller is your MCU using, and what sort of properties does it have. The normal M-Cortex NVIC defaults to priority 0, which is the HIGHEST priority, and in fact TOO high for FreeRTOS, so not setting priorities guarantees that you are doing it wrong. (I donāt see where youāve mentioned the processor, which is very important for this sort of issue)
I believe I mentioned it further up in the chain but I could be misremembering. I am using the RM44L520 which uses two Arm Cortex-R4F in lockstep. I have the MPU disabled atm.
if there is no max syscall defined then you appear to have an unusual implementation of your mcu port. Unless we get to see it, I am afraid your only option is to contact your vendor.
I can send the mcu port, I just canāt send the source files I have created. Please let me know what you need and I can send it over.
I can only speak for myself, but I am hesitant to support and debug third party code in a public support forum. You can publish your port here (typically that is a set of files starting with portā¦ eg port.c, portmacro.h and such residing in a separate directory. However I will only look at it superficially and comment if something strikes me immediately. For third party code you should request support from that third party firstā¦
I understand. I have reached out to TI and I am just waiting on their response. I will report back here once I hear from TI. Thanks again for your help so far.
1 Like
A quick look at the data sheet for the processor, the interrupts (via the channel mappings and vector mappings in the channel) definitely DO have priorities so you should be doing something with them. This sort of code is often expected to be part of the application (and not the port) as the system canāt know your priority needs.
Hello again,
I gained a bit more information about the issue and I figure I should post it here and see what you all think. After going into the freeze I paused the debugger and looked through the registers. After reading the ARM documentation for this processor I found that the CP15 register contains additional information regarding the undefined instruction exception I have been getting. From the data fault status register I found that the undefined instruction exception is due to an AXI Slave Error which is classified as a precise external abort. The Auxiliary Fault Status Register indicated that the source of the error is the BTCM. Both of these seem to point to an issue accessing memory. The R14_UND register apparently contains the address of the instruction which caused the exception, which in my case is 0x0000609C. This address points to the vPortStartFirstTask in the os_port.asm file as shown below:
This is strange as when this exception occurs several tasks have already been created so iām not quite sure why this instruction is being called at that moment. I am still trying to contact TI to get some more information but since the register values have brought be back to a FreeRTOS API call I figured I would see if anyone can make sense of this with the new information.
Hi Andrew, what you see is fairly normal and straightforward. The Cortex, like many MCUs, has two stack pointers, one for supervisor mode, one for thread mode. This roughly corresponds to isr and application code; the supervisor stack is recycled to serve isrs in FreeRTOS after scheduler start. Your fault probably happened within an ISR. The frame there is misleading.
Okay that makes sense, thank you. In TIs HAL generation tool I disabled the MPU, but for some reason the register in CP15 that stores the MPU sub regions value is still set to 12. Since the exceptions seem to point towards and issue accessing memory I figured the MPU may be causing some issues.
Hello everyone,
I was able to find the issue. The undefined instruction exception was caused by not having enough heap space to properly context switch when I had too many tasks. All of the tasks would be created properly at run time but once it reached the last task the heap did not have enough space to properly context switch. I fixed this by increasing the allotted memory space for the heap. Thank you everyone for the help.
Task switching doesnāt need āHeapā, but system stack space (which often shares memory with the heap). You probably want to actually increase the memory reserved for the system stack so the heap allocations never take too much memory and reduce the stack size below what is needed. Increasing the heap sized may have just masked the problem by indirectly giving more space available currently to the system stack as it is using the unused extra heap space.
Alright, I decreased the heap size back to itās original value and increase the system stack size and that seems to work so you must be right about the heap increase fixing the issue by proxy. Thanks again