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.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
