<div dir="ltr"><div dir="ltr">Hi,<div>what does it mean exactly to run with the RTEMS master ?</div><div><br></div><div>The problem is like this: I initially had a USB stack for my STM32F7 that was working on a bareboard (no OS)</div><div>Starting from that, I integrated that USB code in RTEMS 4.11.2. This was a long duration task, until I got it working</div><div>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</div><div>and various other stuff to see it working. </div><div><br></div><div>To try with another RTEMS version would mean redo the USB integration; I can't consider this as a viable option because it</div><div>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.</div><div>I think the only good option would be to debug in my code base and understand what's going on.</div><div><br></div><div>regards,</div><div>Catalin</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 2:03 PM 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 12:46, Catalin Demergian wrote:<br>
> Hi,<br>
> This is the result of task command in shell after SCrx task gets stuck<br>
><br>
> [/] # task<br>
><br>
> ID NAME PRI STATE MODES EVENTS WAITID WAITARG NOTES<br>
><br>
> ------------------------------------------------------------------------------<br>
><br>
> 0a010001 UI1 1 Wevnt P:T:nA NONE 2002a77c 0x80673a3<br>
><br>
> 0a010002 LOGT 99 Wmsg P:T:nA NONE 22010001 0x80673a3<br>
><br>
> 0a010003 ntwk 100 Wsysev P:T:nA NONE 2005d8a4 0x80673a3<br>
><br>
> 0a010004 SCtx 100 Wsysev P:T:nA NONE 2005ed0c 0x80673a3<br>
><br>
> *0a010005 SCrx 100 READY P:T:nA 08000000 2005fd1c 0x80673a3*<br>
><br>
> 0a010006 SHLL 100 READY P:T:nA NONE fef90700 0x80673a3<br>
><br>
> [/] #<br>
><br>
><br>
> SCrx is ready and my USB event is set (08000000); still, SCrx doesn't <br>
> get CPU time.<br>
> Here is the result of cpuuse at two different times<br>
><br>
> [/] # cpuuse<br>
><br>
> -------------------------------------------------------------------------------<br>
><br>
> CPU USAGE BY THREAD<br>
><br>
> ------------+----------------------------------------+---------------+---------<br>
><br>
> ID | NAME | SECONDS | PERCENT<br>
><br>
> ------------+----------------------------------------+---------------+---------<br>
><br>
> 0x09010001 | IDLE | 9218.757029 | 99.562<br>
><br>
> 0x0a010001 | UI1 | 1.067066 | 0.011<br>
><br>
> 0x0a010002 | LOGT | 0.000015 | 0.000<br>
><br>
> 0x0a010003 | ntwk | 0.639828 | 0.006<br>
><br>
> 0x0a010004 | SCtx | 0.199488 | 0.002<br>
><br>
> *0x0a010005 | SCrx | 0.138781 | 0.001*<br>
><br>
> *0x0a010006 | SHLL | 38.550932 | 0.416*<br>
><br>
> ------------+----------------------------------------+---------------+---------<br>
><br>
> TIME SINCE LAST CPU USAGE RESET IN SECONDS: 9259.353153<br>
><br>
> -------------------------------------------------------------------------------<br>
><br>
> [/] #<br>
><br>
> [/] #<br>
><br>
> [/] #<br>
><br>
> [/] # cpuuse<br>
><br>
> -------------------------------------------------------------------------------<br>
><br>
> CPU USAGE BY THREAD<br>
><br>
> ------------+----------------------------------------+---------------+---------<br>
><br>
> ID | NAME | SECONDS | PERCENT<br>
><br>
> ------------+----------------------------------------+---------------+---------<br>
><br>
> 0x09010001 | IDLE | 9223.354634 | 99.560<br>
><br>
> 0x0a010001 | UI1 | 1.067066 | 0.011<br>
><br>
> 0x0a010002 | LOGT | 0.000015 | 0.000<br>
><br>
> 0x0a010003 | ntwk | 0.640091 | 0.006<br>
><br>
> 0x0a010004 | SCtx | 0.199519 | 0.002<br>
><br>
> *0x0a010005 | SCrx | 0.138781 | 0.001*<br>
><br>
> *0x0a010006 | SHLL | 38.674044 | 0.417*<br>
><br>
> ------------+----------------------------------------+---------------+---------<br>
><br>
> TIME SINCE LAST CPU USAGE RESET IN SECONDS: 9264.074153<br>
><br>
><br>
> As seen, the shell task is getting CPU (38.674044 > 38.550932), but <br>
> SCrx is unchanged (0.138781). This is what we know.<br>
<br>
Also the ntwk and SCtx tasks receive some CPU time in between. I guess <br>
the scheduler data structures are somehow corrupt.<br>
<br>
On an ARM Cortex-M system it is very important that all interrupt <br>
service routines using operating system services use the right <br>
entry/exit code and the right interrupt priority.<br>
<br>
I would first try to run your application with the RTEMS master and see <br>
if it behaves differently.<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>