rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
what does it mean exactly to run with the RTEMS master ?

The problem is like this: I initially had a USB stack for my STM32F7 that
was working on a bareboard (no OS)
Starting from that, I integrated that USB code in RTEMS 4.11.2. This was a
long duration task, until I got it working
a spent a lot if time changing the makefiles first to add my new files to
the project, then analysing the USB bus with a sniffer
and various other stuff to see it working.

To try with another RTEMS version would mean redo the USB integration; I
can't consider this as a viable option because it
would take a long time until I would be in the same place, and there are no
guarantees it will not fail in the same way.
I think the only good option would be to debug in my code base and
understand what's going on.

regards,
Catalin

On Tue, Sep 25, 2018 at 2:03 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180925/88c67ba1/attachment-0002.html>