rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,

Did you add your code to the RTEMS source tree?
-> yes, I had to add the USB files, because there was no USB support in my
code base

There are new fatal errors in the master branch
INTERNAL_ERROR_THREAD_QUEUE_ENQUEUE_STICKY_FROM_BAD_STATE,
INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL, and
INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT
which may help to detect a problem you encountered.
-> changing the RTEMS code base and try it would mean a lot of work,
because I would have to
re-integrate my USB code in it, it will probably won't work right away,
like it was the case for RTEMS 4.11.2,
debug a lot, sniff the USB line with an analyzer, and so on ... the effort
is big, and if I will have the same issue
in the new code it will all be for nothing, because I will have to debug
the issue in the new code after all.
*The error codes INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL and*
*INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT seem interesting ... what
would be really helpful is*
*to integrate only these changes in my codebase as a patch ... can you
refer me to those patches ?*

You can also use the --enable-rtems-debug configure option
-> yes, that seems like a good idea; how does it work ? when it detects an
inconsistency it is displayed at the console ?
or in order to see if there was an inconsistency I have to enter some
commands in the shell ?

regards,
Catalin


On Wed, Sep 26, 2018 at 8:00 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 25/09/2018 13:37, Catalin Demergian wrote:
> > Hi,
> > what does it mean exactly to run with the RTEMS master ?
>
> The RTEMS Git master branch.
>
> >
> > 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.
>
> The RTEMS APIs didn't change that much between the RTEMS 4.11 release
> and the Git master. Did you add your code to the RTEMS source tree?
>
> There are new fatal errors in the master branch
> INTERNAL_ERROR_THREAD_QUEUE_ENQUEUE_STICKY_FROM_BAD_STATE,
> INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL, and
> INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT
> which may help to detect a problem you encountered.
>
> You can also use the --enable-rtems-debug configure option. It is
> available in RTEMS 4.11, however, in the RTEMS master there are more
> internal consistency checks. This would be helpful to track down a
> potential scheduler bug (I don't expect a bug in this area).
>
> --
> 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/20180926/8b2ecbb2/attachment-0002.html>