<div dir="ltr">Hi,<div><br></div><div>Did you add your code to the RTEMS source tree? </div><div>-> yes, I had to add the USB files, because there was no USB support in my code base</div><div><br></div><div>There are new fatal errors in the master branch<br>INTERNAL_ERROR_THREAD_QUEUE_ENQUEUE_STICKY_FROM_BAD_STATE,<br>INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL, and<br>INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT<br>which may help to detect a problem you encountered. </div><div>-> changing the RTEMS code base and try it would mean a lot of work, because I would have to<br></div><div>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,</div><div>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</div><div>in the new code it will all be for nothing, because I will have to debug the issue in the new code after all.</div><div><b>The error codes INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL and</b></div><b>INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT seem interesting ... what would be really helpful is</b><div><b>to integrate only these changes in my codebase as a patch ... can you refer me to those patches ?</b></div><div><br><div>You can also use the --enable-rtems-debug configure option </div><div>-> yes, that seems like a good idea; how does it work ? when it detects an inconsistency it is displayed at the console ?</div><div>or in order to see if there was an inconsistency I have to enter some commands in the shell ? <br><div><br></div><div>regards,</div><div>Catalin</div><div> <br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018 at 8:00 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25/09/2018 13:37, Catalin Demergian wrote:<br>
> Hi,<br>
> what does it mean exactly to run with the RTEMS master ?<br>
<br>
The RTEMS Git master branch.<br>
<br>
><br>
> The problem is like this: I initially had a USB stack for my STM32F7 <br>
> that was working on a bareboard (no OS)<br>
> Starting from that, I integrated that USB code in RTEMS 4.11.2. This <br>
> was a long duration task, until I got it working<br>
> a spent a lot if time changing the makefiles first to add my new files <br>
> to the project, then analysing the USB bus with a sniffer<br>
> and various other stuff to see it working.<br>
><br>
> To try with another RTEMS version would mean redo the USB integration; <br>
> I can't consider this as a viable option because it<br>
> would take a long time until I would be in the same place, and there <br>
> are no guarantees it will not fail in the same way.<br>
> I think the only good option would be to debug in my code base and <br>
> understand what's going on.<br>
<br>
The RTEMS APIs didn't change that much between the RTEMS 4.11 release <br>
and the Git master. Did you add your code to the RTEMS source tree?<br>
<br>
There are new fatal errors in the master branch<br>
INTERNAL_ERROR_THREAD_QUEUE_ENQUEUE_STICKY_FROM_BAD_STATE,<br>
INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL, and<br>
INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT<br>
which may help to detect a problem you encountered.<br>
<br>
You can also use the --enable-rtems-debug configure option. It is <br>
available in RTEMS 4.11, however, in the RTEMS master there are more <br>
internal consistency checks. This would be helpful to track down a <br>
potential scheduler bug (I don't expect a bug in this area).<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div>