ticker hangs on bf537Stamp

[Sebastian Huber]

Hello Kolja,

maybe the Blackfin exception processing is broken.

You can set a break point to _Thread_Delay_ended().  This function will be 
called once the time specified at rtems_task_wake_after() elapsed.  The next 
_Thread_Dispatch() call (executed in the exception epilogue) must perform a 
context switch to a non-idle task in the ticker example in this case.

On 2013-10-15 12:51, Kolja Waschk wrote:
> Hi,
>
> I'm evaluating RTEMS for a Blackfin ADSP-BF537 based custom board, similar to
> the BF537-STAMP with even less peripherals.
>
> The ticker example halts after printing one line from each started task,
> although I was able to verify (with gdb via JTAG) that rtems_clock_ticks() is
> indeed called at 100 Hz and ticks are incremented.
>
> Reducing the tick count argument to rtems_task_wake_after() in Test_task to "1"
> lets all tasks run until 35s are reached, but with larger values the test comes
> to an early halt.
>
> The following output of modified ticker with rtems_task_wake_after(ticks=1) and
> added output of rtems_clock_get_ticks_since_boot() (between asterisks) proves
> the incrementing tick count:
>
> ...
> TA3  *3297*  - rtems_clock_get_tod - 09:00:32   12/31/1988
> TA1  *3298*  - rtems_clock_get_tod - 09:00:32   12/31/1988
> TA2  *3298*  - rtems_clock_get_tod - 09:00:32   12/31/1988
> TA3  *3299*  - rtems_clock_get_tod - 09:00:32   12/31/1988
> TA1  *3300*  - rtems_clock_get_tod - 09:00:32   12/31/1988
> ...
>
> But with original tasks.c the output is just as described in an earlier message
> here on the list regarding "bfin simulator problems":
> http://www.rtems.org/pipermail/rtems-users/2013-May/011544.html
>
> Does this sound familiar to anyone? The board is almost uninitialized except
> for PLL, SDRAM, Flash. RTC has no crystal connected but RTC is not important
> for ticker, is it? (If it is, how can I get rid of this dependency?)
>
> The rtems-python scripts for GDB told me that tasks soon become "ready" but I
> they actually don't execute. GDB shows the CPU is only looping
> _CPU_Thread_Idle_body, interrupted by clockISR, but no task switch ever occurs.
> E.g.:
>
> (gdb) rtems task 2
>       Name: TA1
>      State: ready
>
> The rtems wdticks output in this state is (to me) a little strange, but this
> may be also caused by script vs. architecture inconsistencies? The "WD Routine"
> points to nowhere. Maybe this gives a clue?
>
> (gdb) rtems wdticks
>    #0
>       State:being-inserted
>       Intial Interval:0
>       Delta Interval:1
>       Start time:1
>       Stop time:151060481
>       WD Routine:0x9010001
>   #1
>       State:being-inserted
>       Intial Interval:0
>       Delta Interval:1
>       Start time:1
>       Stop time:151060481
>       WD Routine:0x9010001
>
>
> Thanks in advance for any hints regarding this!
>
> Kolja
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.