# Queue Problem **URL:** \ **Category:** Kernel\ **Created:** [March 15, 2008, 9:19pm UTC](https://forums.freertos.org/t/queue-problem/2579 "2008-03-15T21:19:21Z")\ **Posts on this page:** 7\ **Page:** 2
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [August 14, 2008, 5:56pm UTC](https://forums.freertos.org/t/queue-problem/2579/21 "2008-08-14T17:56:27Z")
**[daworm](https://sourceforge.net/u/daworm/)** wrote on [Thursday, August 14, 2008](https://sourceforge.net/p/freertos/discussion/382005/thread/733a936c/#1097/9cc2): Working on that right now.  I use this board: [http://www.st.com/mcu/contentid-100-110-STM3210B\_EVAL.html](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. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [August 14, 2008, 8:12pm UTC](https://forums.freertos.org/t/queue-problem/2579/22 "2008-08-14T20:12:23Z")
**[daworm](https://sourceforge.net/u/daworm/)** wrote on [Thursday, August 14, 2008](https://sourceforge.net/p/freertos/discussion/382005/thread/733a936c/#1097/7d0d/8e2e/f3d0): Sample project sent via email.  Thanks! Jeff. ---
**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:** [August 16, 2008, 12:45pm UTC](https://forums.freertos.org/t/queue-problem/2579/23 "2008-08-16T12:45:56Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, August 16, 2008](https://sourceforge.net/p/freertos/discussion/382005/thread/733a936c/#1097/7d0d/8e2e/f3d0/b49f): Please see my notes at the end of this thread for at least part of a conclusion… Regards. ---
**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:** [August 16, 2008, 12:52pm UTC](https://forums.freertos.org/t/queue-problem/2579/24 "2008-08-16T12:52:36Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Saturday, August 16, 2008](https://sourceforge.net/p/freertos/discussion/382005/thread/733a936c/#1097/a735): 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](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. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [August 18, 2008, 1:00pm UTC](https://forums.freertos.org/t/queue-problem/2579/25 "2008-08-18T13:00:05Z")
**[daworm](https://sourceforge.net/u/daworm/)** wrote on [Monday, August 18, 2008](https://sourceforge.net/p/freertos/discussion/382005/thread/733a936c/#1097/755b): \* Repeated from private email at Richard’s request \*   This does indeed look like it fixed the problem (boy, I hate stupid user errors \).  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. ---
**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:** [August 18, 2008, 1:13pm UTC](https://forums.freertos.org/t/queue-problem/2579/26 "2008-08-18T13:13:51Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, August 18, 2008](https://sourceforge.net/p/freertos/discussion/382005/thread/733a936c/#1097/755b/53f0): \>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](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. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 22, 2011, 7:03am UTC](https://forums.freertos.org/t/queue-problem/2579/27 "2011-05-22T07:03:19Z")
**[pjansen](https://sourceforge.net/u/pjansen/)** wrote on [Sunday, May 22, 2011](https://sourceforge.net/p/freertos/discussion/382005/thread/733a936c/#f183): 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. [Previous page](https://forums.freertos.org/t/queue-problem/2579.md?page=1)