rtems_message_queue_receive / rtems_event_receive issues

[Sebastian Huber]

On 25/09/2018 12:46, Catalin Demergian wrote:
> Hi,
> This is the result of task command in shell after SCrx task gets stuck
>
> [/] # task
>
> ID NAME           PRI STATE MODES   EVENTS    WAITID  WAITARG NOTES
>
> ------------------------------------------------------------------------------
>
> 0a010001 UI1 1 Wevnt  P:T:nA    NONE   2002a77c 0x80673a3
>
> 0a010002 LOGT            99 Wmsg   P:T:nA    NONE   22010001 0x80673a3
>
> 0a010003 ntwk           100 Wsysev P:T:nA    NONE   2005d8a4 0x80673a3
>
> 0a010004 SCtx           100 Wsysev P:T:nA    NONE   2005ed0c 0x80673a3
>
> *0a010005 SCrx           100 READY  P:T:nA  08000000 2005fd1c 0x80673a3*
>
> 0a010006 SHLL           100 READY  P:T:nA    NONE   fef90700 0x80673a3
>
> [/] #
>
>
> SCrx is ready and my USB event is set (08000000); still, SCrx doesn't 
> get CPU time.
> Here is the result of cpuuse at two different times
>
> [/] # cpuuse
>
> -------------------------------------------------------------------------------
>
>   CPU USAGE BY THREAD
>
> ------------+----------------------------------------+---------------+---------
>
> ID | NAME | SECONDS       | PERCENT
>
> ------------+----------------------------------------+---------------+---------
>
> 0x09010001 | IDLE |   9218.757029 |  99.562
>
> 0x0a010001 | UI1 |      1.067066 |   0.011
>
> 0x0a010002 | LOGT |      0.000015 |   0.000
>
> 0x0a010003 | ntwk |      0.639828 |   0.006
>
> 0x0a010004 | SCtx |      0.199488 |   0.002
>
> *0x0a010005 | SCrx                 | 0.138781 |   0.001*
>
> *0x0a010006 | SHLL |     38.550932 |   0.416*
>
> ------------+----------------------------------------+---------------+---------
>
> TIME SINCE LAST CPU USAGE RESET IN SECONDS:             9259.353153
>
> -------------------------------------------------------------------------------
>
> [/] #
>
> [/] #
>
> [/] #
>
> [/] # cpuuse
>
> -------------------------------------------------------------------------------
>
> CPU USAGE BY THREAD
>
> ------------+----------------------------------------+---------------+---------
>
> ID | NAME | SECONDS       | PERCENT
>
> ------------+----------------------------------------+---------------+---------
>
> 0x09010001 | IDLE |   9223.354634 |  99.560
>
> 0x0a010001 | UI1 |      1.067066 |   0.011
>
> 0x0a010002 | LOGT |      0.000015 |   0.000
>
> 0x0a010003 | ntwk                           | 0.640091 |   0.006
>
> 0x0a010004 | SCtx |      0.199519 |   0.002
>
> *0x0a010005 | SCrx |      0.138781 |   0.001*
>
> *0x0a010006 | SHLL        |     38.674044 |   0.417*
>
> ------------+----------------------------------------+---------------+---------
>
> TIME SINCE LAST CPU USAGE RESET IN SECONDS: 9264.074153
>
>
> As seen, the shell task is getting CPU (38.674044 > 38.550932), but 
> SCrx is unchanged (0.138781). This is what we know.

Also the ntwk and SCtx tasks receive some CPU time in between. I guess 
the scheduler data structures are somehow corrupt.

On an ARM Cortex-M system it is very important that all interrupt 
service routines using operating system services use the right 
entry/exit code and the right interrupt priority.

I would first try to run your application with the RTEMS master and see 
if it behaves differently.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.