On 25/10/2018 13:51, Catalin Demergian wrote:
btw, is there a unit test somewhere for the chain implementation?
otherwise I will think of a small program where I will try to make it
fail with
double insert/erase.
Yes, for example this one:
testsuites/sptests/spchain/init.c
--
Sebastian
On 25/10/2018 13:03, Catalin Demergian wrote:
This is really strange. If you use cpsid/cpsie around the append_cnt ++
and --, then append_cnt should never be > 1. If this really the case,
then this looks like a processor bug.
-> No, after I saw that it didn't fix the problem I commented the
This is really strange. If you use cpsid/cpsie around the append_cnt ++
and --, then append_cnt should never be > 1. If this really the case,
then this looks like a processor bug.
-> No, after I saw that it didn't fix the problem I commented the dis/en,
so
the value 2 was obtained without the
On 25/10/2018 11:00, Catalin Demergian wrote:
Hi,
First, I would like to conceptually understand how a function as
simple as _Chain_Append_unprotected could fail.
The chain operations fail if you try to append a node that is already on
a chain or extract a node which is not on a chain.
I
Hi,
First, I would like to conceptually understand how a function as simple
as _Chain_Append_unprotected could fail.
I added a patch like this
RTEMS_INLINE_ROUTINE void _Chain_Append_unprotected(
Chain_Control *the_chain,
Chain_Node*the_node
)
{
append_cnt++;
if(append_cnt >
On 24/10/2018 11:10, Catalin Demergian wrote:
Hi,
I made a debug patch with some changes
in _Scheduler_priority_Ready_queue_enqueue
if(tcb->Object.id == 0x0a010005)
cnt_before = _Chain_Node_count_unprotected(ready_chain);
_Chain_Append_unprotected( ready_chain, node );
Hi,
I made a debug patch with some changes
in _Scheduler_priority_Ready_queue_enqueue
if(tcb->Object.id == 0x0a010005)
cnt_before = _Chain_Node_count_unprotected(ready_chain);
_Chain_Append_unprotected( ready_chain, node );
if(tcb->Object.id == 0x0a010005) {
cnt_after =
On 23/10/2018 10:44, Catalin Demergian wrote:
Hi,
I'm logging what rtems_clock_get_ticks_since_boot returns to know when
I call _Scheduler_priority_Ready_queue_enqueue
and _Scheduler_priority_Ready_queue_extract, but I'm getting the same
number, I can't tell the order. My question is,
do you
Hi,
I'm logging what rtems_clock_get_ticks_since_boot returns to know when I
call _Scheduler_priority_Ready_queue_enqueue
and _Scheduler_priority_Ready_queue_extract, but I'm getting the same
number, I can't tell the order. My question is,
do you know if there is something I can call that gives me
On 22/10/2018 15:00, Catalin Demergian wrote:
I started to look in the ready queues implementation. I added a debug
patch tracing my tasks having priority=100.
The way I see it, a task can enter a ready queue only
with
Hi,
I'm back investigating this issue.
I started to look in the ready queues implementation. I added a debug patch
tracing my tasks having priority=100.
The way I see it, a task can enter a ready queue only
with
On 12/10/2018 10:40, Catalin Demergian wrote:
Hi,
I still think it would be worth to try the latest RTEMS master just to
make sure we don't search a bug which is already fixed. Also RTEMS 5 has
more assertions in the debug configuration.
-> is RTEMS 5 stable branch or development ?
It is the
Hi,
I still think it would be worth to try the latest RTEMS master just to
make sure we don't search a bug which is already fixed. Also RTEMS 5 has
more assertions in the debug configuration.
-> is RTEMS 5 stable branch or development ?
-> what is the link for RTEMS master (where to do a git clone
On 11/10/2018 15:37, Catalin Demergian wrote:
Hi,
Yes, there is a call to rtems_task_wake_after in the code; but in that
case state should have been STATES_DELAYING, right ?
The
state = 0x0 = STATES_READY
Wait.flags = 0x02 = THREAD_WAIT_STATE_BLOCKED
looks suspicious. It should be
state =
Hi,
Yes, there is a call to rtems_task_wake_after in the code; but in that case
state should have been STATES_DELAYING, right ?
At another run, I got
state = 0x0 = STATES_READY
Wait.flags = 0x104 = THREAD_WAIT_CLASS_EVENT | THREAD_WAIT_STATE_READY_AGAIN
Why would the state be ready in _Event_Seize
On 11/10/2018 09:52, Catalin Demergian wrote:
Hi,
I don't use malloc myself in the code I added, but I see it is used a
lot in the networking code.
I printed state and Wait.flags for SCrx task
* when all is ok *
in _Event_Seize, after _Thread_Dispatch_enable
state = 0x100 =
Hi,
I don't use malloc myself in the code I added, but I see it is used a lot
in the networking code.
I printed state and Wait.flags for SCrx task
* when all is ok *
in _Event_Seize, after _Thread_Dispatch_enable
state = 0x100 = STATES_WAITING_FOR_EVENT
Wait.flags = 0x102 =
On 10/10/2018 16:18, Catalin Demergian wrote:
Hi,
I got into another issue when I tried ping -f
[/] # assertion "the_watchdog->state == WATCHDOG_ACTIVE" failed: file
"../../../../../../c/src/../../cpukit/score/src/watchdogremove.c",
line 34, function: _Watchdog_Remove_it
*** PROFILING
>
> Hi,
I got into another issue when I tried ping -f
[/] # assertion "the_watchdog->state == WATCHDOG_ACTIVE" failed: file
"../../../../../../c/src/../../cpukit/score/src/watchdogremove.c", line 34,
function: _Watchdog_Remove_it
*** PROFILING REPORT BEGIN PMC_APP ***
2
1
On 10/10/2018 14:27, Catalin Demergian wrote:
I was debugging to follow what's going on with the state of the task
in _Event_Seize and
when trying to step over _Thread_Dispatch_enable( cpu_self ) call at
the end of the function I got this in the debugger
Hi,
we ran those tests and they all passed.
I was debugging to follow what's going on with the state of the task in
_Event_Seize and
when trying to step over _Thread_Dispatch_enable( cpu_self ) call at the
end of the function I got this in the debugger
On 09/10/2018 08:48, Catalin Demergian wrote:
Hi,
I put more debugging effort into this.
I think it's all about the Wait.flags value when the ISR is arriving.
For Wait.flags=BLOCKED or Wait.flags=INTEND_TO_BLOCK things are working
(yes, _Thread_Unblock is called from _Event_Seize properly), but
Hi,
I put more debugging effort into this.
I think it's all about the Wait.flags value when the ISR is arriving.
For Wait.flags=BLOCKED or Wait.flags=INTEND_TO_BLOCK things are working
(yes, _Thread_Unblock is called from _Event_Seize properly), but when
Wait.flags=READY
things don't work because
Hi,
First of all, I verified if I have this fix in my code base and I do have
it.
"Are the flags == 0x101? In this case the thread is in the middle of
_Event_Seize()"
Yes. Even if in my test the ping packets arrive once at every second
and there is plenty of time, sometimes it
happens that
On 04/10/2018 15:33, Catalin Demergian wrote:
I eliminated the theory of memory corruption. I debugged and found we
set Wait.flags = 0x104 with a function call.
The USB interrupt can arrive at any time, so Wait.flags can be either
INTEND_TO_BLOCK, BLOCKED or READY_AGAIN.
Following the logic
Hi,
I eliminated the theory of memory corruption. I debugged and found we set
Wait.flags = 0x104 with a function call.
The USB interrupt can arrive at any time, so Wait.flags can be either
INTEND_TO_BLOCK, BLOCKED or READY_AGAIN.
Following the logic in _Event_Surrender:
If it arrives when
ok, I understand. The code in _Event_Is_blocking_on_event is correct, it
just verifies if the thread is in wait state or not.
The only thing that varies is what _Thread_Wait_flags_get returns. In my
case, it returned 0x102 for 5401 times,
but 5402th time it returned 0x104; because of that, (
Hi,
I continued debugging.
It turned out _Thread_Unblock is not called because in _Event_Surrender
(called directly by rtems_event_send) boolean var unblock is false.
to be more exact, in
if (
_Event_Is_blocking_on_event( the_thread, wait_class )
&& _Event_Is_satisfied( the_thread,
On 02/10/2018 08:48, Catalin Demergian wrote:
Hi,
This assert may not be directly related to my issue because I
reproduced it a few times (with RTEMS_DEBUG enabled in the build)
without seeing the assert being hit. What I discovered is that after a
while _Scheduler_priotity_Unblock is not
Hi,
This assert may not be directly related to my issue because I reproduced it
a few times (with RTEMS_DEBUG enabled in the build)
without seeing the assert being hit. What I discovered is that after a
while _Scheduler_priotity_Unblock is not called for my task anymore.
And since
I'm using 4.11.2
Catalin
On Mon, Oct 1, 2018 at 10:16 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 01/10/2018 08:55, Catalin Demergian wrote:
> > Hello,
> > After enabling RTEMS_DEBUG like you told me, I found the test I left
> > running over the weekend like this
> >
>
On 01/10/2018 08:55, Catalin Demergian wrote:
Hello,
After enabling RTEMS_DEBUG like you told me, I found the test I left
running over the weekend like this
[/] #
[/] #
[/] # assertion "first != _Chain_Tail( _queues[ index ] )"
failed: file
Hello,
After enabling RTEMS_DEBUG like you told me, I found the test I left
running over the weekend like this
[/] #
[/] #
[/] # assertion "first != _Chain_Tail( _queues[ index ] )" failed:
file
"../../cpukit/../../../stm32f7/lib/include/rtems/score/schedulerpriorityimpl.h",
line 166, function:
Yes, I can use prints at the console.
On Mon, Oct 1, 2018, 08:46 Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 27/09/2018 15:47, Catalin Demergian wrote:
> > I tried the idea with RTEMS_DEBUG, but I could reproduce the problem
> > and nothing appeared in the console.
> >
On 27/09/2018 15:47, Catalin Demergian wrote:
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 ..
Works printk() on
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
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
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
On 26/09/2018 09:21, Catalin Demergian wrote:
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
If you integrate code into the RTEMS source tree, then you should use
the master branch and try to upstream
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,
HI,
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
Did you merge your code into the RTEMS
source tree?
-> yes, there was no support for USB in the code base I had
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
On 25/09/2018 21:37, Catalin Demergian wrote:
> what does it mean exactly to run with the RTEMS master ?
This is our short hand for saying use the development version of RTEMS,
specifically the next release called RTEMS 5. It requires cloning a couple of
git repos and using them rather than the
Hi,
what does it mean exactly to run with the RTEMS master ?
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
On 25/09/2018 12:46, Catalin Demergian wrote:
Hi,
This is the result of task command in shell after SCrx task gets stuck
[/] # task
ID NAME PRI STATE MODES EVENTS WAITID WAITARG NOTES
--
0a010001 UI1
Hi,
This is the result of task command in shell after SCrx task gets stuck
[/] # task
ID NAME PRI STATE MODES EVENTSWAITID WAITARG
NOTES
--
0a010001 UI1 1 Wevnt P:T:nANONE
On 21/09/2018 08:59, Catalin Demergian wrote:
So my question is: why would a task stop getting CPU time ?
In RTEMS you have priority based schedulers. If there is a higher
priority ready thread then a lower priority thread will not run.
Where is the code in the RTEMS scheduler that decides
Hi,
I saw an event basically means setting a bit in a 32 bit integer, so, yes,
they don't queue.
I got into the same issue with
rtems_message_queue_receive(RTEMS_NO_TIMEOUT), it blocks even
if there are messages in the queue like I said. Not even
rtems_message_queue_receive without timeout
didn't
Also the subject says message queue and event receive but the scenario
described is just about events. Events do not queue. They are one deep. If
the receiving task ever misses an event send (2 sends before.one receive),
then the described scenario.is expected.
--joel
On Thu, Sep 20, 2018, 7:44
On 20/09/2018 15:48, Catalin Demergian wrote:
Hi,
I'm using
#define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)
13*16=208 > 0x80=128, so I should be on the safe side.
what do you mean by operating system services ?
Everything which uses rtems_interrupt_disable() or
_Thread_Dispatch_disable().
Hi,
I'm using
#define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)
13*16=208 > 0x80=128, so I should be on the safe side.
what do you mean by operating system services ? like rtems_event_send in
ISR ?
is there other way to handle USB data other than copy data in a buffer in
ISR and signal a kernel
Hello Catalin,
could you please check if you have the same behaviour on the RTEMS master.
On ARMv-7M and RTEMS exceptions and interrupts with a priority value of
less than 0x80 are non-maskable with respect to the operating system and
therefore must not use operating system services. If you
Hi,
I'm using rtems_interrupt_handler_install now, the issue is the same.
Let me provide some context.
I use an IP layer (SLIP protocol) above the USB so datagrams can flow over
USB.
I'm sending ping packets in loop in a long duration test. After 1/2/3 hours
(it varies),
I don't reply to ping
Hi Catalin,
Please also make sure that the clock ISR is installed
via rtems_interrupt_handler_install().
Actually, in order to check whether scheduler works well, you can set a
break point at clock ISR or keep track of 'tick' variable. I think that
your USB ISR does not complete and further
On 19/09/2018 14:46, Catalin Demergian wrote:
I installed the ISR myself like this
// USB related initializations
_ARMV7M_Set_exception_priority_and_handler(ARMV7M_VECTOR_IRQ(STM32F7_IRQ_OTG_FS),
BSP_ARMV7M_IRQ_PRIORITY_DEFAULT, USB_OTG_Handler);
I am sure that the ISR is entered after
Hi,
thank you for answering !
I am using my own queues and rtems_event_send to notify my kernel task from
the USB ISR that a new packet arrived.
I found an interesting field in the TCB structure
/** This field is the amount of CPU time consumed by this thread
* since it was created.
*/
On Tue, Sep 18, 2018, 9:59 PM Mingyu Li wrote:
> Hi Catalin.
>
> I find the problem you encountered interesting. I hope to offer some hints
> that might be helpful to you:
>
> 1. use a user task to first rtems_event_send then rtems_event_receive, in
> order to make sure the internal IPC of RTEMS
Hi Catalin.
I find the problem you encountered interesting. I hope to offer some hints
that might be helpful to you:
1. use a user task to first rtems_event_send then rtems_event_receive, in
order to make sure the internal IPC of RTEMS kernel you are using (4.11.2)
works as expected.
2. ensure
58 matches
Mail list logo
