ticker hangs on bf537Stamp
rtemsdev at ixo.de
Tue Oct 15 10:51:23 UTC 2013
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
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
Thanks in advance for any hints regarding this!
More information about the users