rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
I tried the idea with RTEMS_DEBUG, but I could reproduce the problem and
nothing appeared in the console.
this time it happened after 16366 ping packets .. I think I have to debug
step-by-step in Eclipse to get more info now ..

regards,
Catalin


On Wed, Sep 26, 2018 at 11:38 AM Catalin Demergian <demergian at gmail.com>
wrote:

> Hi,
> Are you able to catch the interrupt, confirm the event is being raised and
> the
> interrupt exits via the RTEMS exit path?
> -> Yes. I can see with task command in shell my USB event is set for my
> task; the state is READY, but
> if I enter cpuuse a few times I see the total CPU time for my task doesn't
> increase, but for other tasks it increases.
> I also see interrupts comming at every second (as ping send packets every
> second) and my buffer of packets eventually gets full.
>
> That's why I say that maybe something happens in the dispatcher, because
> the dispacther should take tasks from the ready queue
> and put them on the CPU.
>
> regards,
> Catalin
>
>
>
>
> On Wed, Sep 26, 2018 at 10:54 AM Chris Johns <chrisj at rtems.org> wrote:
>
>> On 26/09/2018 16:43, Catalin Demergian wrote:
>> > When you say "changing the makefiles" who's makefiles are these?
>> > -> for example lib/rtems-4.11.2/c/src/lib/libbsp/arm/stm32f7/Makefile.am
>> > in order to include my USB .c and .h files
>>
>> Thanks.
>>
>> > Did you merge your code into the RTEMS
>> > source tree?
>> > -> yes, there was no support for USB in the code base I had
>>
>> Sure and thanks.
>>
>> RTEMS is statically linked so object files built as part of RTEMS or
>> files build
>> as part of your code are equivalent.
>>
>> I will often create a small application to test new drivers or a new
>> feature for
>> RTEMS that do not touch the core RTEMS kernel code. I do this because the
>> build
>> is simpler and faster than rebuilding RTEMS on each edit. This means
>> updating
>> RTEMS is easy and the code I have is not effected.
>>
>> >
>> > Do you have a JTAG debugger that can set breakpoints and step at the
>> instruction
>> > level?
>> > -> yes
>> >
>>
>> Are you able to catch the interrupt, confirm the event is being raised
>> and the
>> interrupt exits via the RTEMS exit path?
>>
>> Chris
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180927/e4ec9529/attachment-0002.html>