daworm wrote on Thursday, August 14, 2008:
Working on that right now. I use this board:
http://www.st.com/mcu/contentid-100-110-STM3210B_EVAL.html
All the demo will need to run on is two serial ports, I hope. Will let you know as soon as I get it built and verify it hangs in the same manner.
Jeff.
rtel wrote on Saturday, August 16, 2008:
Please see my notes at the end of this thread for at least part of a conclusion…
Regards.
rtel wrote on Saturday, August 16, 2008:
Having reviewed a project in which the use of multiple queues was causing a crash - it would seem that the immediate problem was in fact priority assignments caused by the counter intuitive way priorities are specified on Cortex M3 parts. I have just added the following note to the page: http://www.freertos.org/a00110.html#kernel_priority to beef up the documentation on this a bit:
"A special note for Cortex M3 users: Remember that Cortex M3 cores use numerically low priority numbers to represent HIGH priority interrupts, which can seem counter-intuitive and is easy to forget! If you wish to assign an interrupt a low priority do NOT assign it a priority of 0 (or other low numeric value) as this can result in the interrupt actually having the highest priority in the system - and therefore potentially make your system crash if this priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY.
The lowest priority on a Cortex M3 core is in fact 255 - however different Cortex M3 vendors implement a different number of priority bits and supply library functions that expect priorities to be specified in different ways. For example, on the STM32 the lowest priority you can specify in an ST driver library call is in fact 15 - and the highest priority you can specify is 0."
I will add similar text to each Cortex M3 port documentation page when I get the chance.
Interrupt nesting and the use of multiple queues has been thoroughly tested on the Cortex M3 core through the use of the IntQueue.c standard demo tasks. This generates two queues that are then read from and written to by two interrupts and 2 tasks each - with both interrupts operating at different priorities and therefore nesting with each other. This test has run for many days without reporting any problems or crashing. While I can never guarantee the absence of bugs, the fact this test passes gives a high degree of confidence in this particular part of the code for Cortex M3 implementations.
Regards.
daworm wrote on Monday, August 18, 2008:
* Repeated from private email at Richard’s request *
This does indeed look like it fixed the problem (boy, I
hate stupid user errors <grin>). However, it does bring up
an issue. Should configLIBRARY_KERNEL_INTERRUPT_PRIORITY
default to the LOWEST priority, or should it be the HIGHEST
priority? Or some value in the middle? Also, I see that
only a small number of architectures support different
priority levels. Among them, should the mechanisms be hidden
in the portability modules?
Thanks,
Jeff.
rtel wrote on Monday, August 18, 2008:
>Should configLIBRARY_KERNEL_INTERRUPT_PRIORITY
>default to the LOWEST priority, or should it be the HIGHEST
>priority? Or some value in the middle?
Probably neither - it should be set to whatever configMAX_SYSCALL_INTERRUPT_PRIORITY is set to. However, configMAX_SYSCALL_INTERRUPT_PRIORITY is set using a numeric value that the Cortex-M3 core understands (interrupt priorities 0 to 255), whereas the ST libraries remap these interrupt priorities to 0 to 15 as only 4 bits of priority are implemented, therefore configLIBRARY_KERNEL_INTERRUPT_PRIORITY is provided in an attempt to be helpful in showing what value should be used when making calls to the ST provided library…confusing isn’t it, but this is how the ST libraries have been implemented so there is nothing I can do about it unfortunately.
Please refer to http://www.freertos.org/a00110.html#kernel_priority - taking account of the fact that the diagram uses high numbers to denote high priorities which is the opposite way around to the Cortex M3.
>Also, I see that
>only a small number of architectures support different
>priority levels. Among them, should the mechanisms be hidden
>in the portability modules?
The architectures that support it are more fully featured - providing users will great flexibility in how interrupt priorities are set. As always with flexibility comes complexity. If you don’t want to use full interrupt nesting then then simply set all interrupts that make API calls to the lowest priority value (255 in Cortex speak, 15 in ST speak).
Regards.
pjansen wrote on Sunday, May 22, 2011:
I’m still having this problem,
when for the USART TX queue gets to pcWriteTo 0x200016CA pcReadFrom 0x200016CA things don’t work properly.
In FreeRTOSConfig.h I have
#define configKERNEL_INTERRUPT_PRIORITY (10 * 16)
#define configMAX_SYSCALL_INTERRUPT_PRIORITY (14 * 16)
/* This is the value being used as per the ST library which permits 16
priority values, 0 to 15. This must correspond to the
configKERNEL_INTERRUPT_PRIORITY setting. Here 15 corresponds to the lowest
NVIC value of 255. */
#define configLIBRARY_KERNEL_INTERRUPT_PRIORITY 10
I had tried the values in the Demo, but still get the same result, using the Demo FreeRTOSV7.0.0/Demo/CORTEX_STM32F103_IAR
I’m using GCC and most other things work, just the TX serial Queue has some problem.