Hello Peter,
I ran some tests with out MPC5566EVB.
It seems you encountered a general problem with the RTEMS test suite. Some
tests (they are all broken from my point of view) assume that output functions
don't block.
So for example in sp02 I get this output:
*** TEST 2 ***
INIT - rtems_task_wake_after - yielding processorPREEMPT - rtems_task_delete -
deleting self
rtems_task_create of TA3 FAILED -- expected (RTEMS_SUCCESSFUL) got
(RTEMS_TOO_MANY)
The preempt task is supposed to delete itself, but it cannot do this action
since it blocks on the puts(). Now the main thread continues and fails due to
the not deleted preempt task.
One workaround for this is to disable interrupt driven console output.
On 2014-02-17 00:44, Peter Dufault wrote:
On Feb 15, 2014, at 09:56 , Peter Dufault <dufa...@hda.com> wrote:
-- sp02, try increasing the number of tasks to 8 (optimization on): Gets an
exception, not clear where, the stack trace is below. Setting a hardware
breakpoint where _Thread_Start_multitasking() returns doesn't break there, as
it seemed to yesterday. I'll try to look some more later, I'll probably
rebuild without optimization (for debugging ease) and start stepping through
sp02 to see why it is failing with the number of tasks set to 4.
This post has a summary of what I found today (nothing), a question about if the jumbled
".scn" test results are expected (probably), and a question about RTEMS test
results and if they are regularly reported on-line.
I rebuilt RTEMS without optimization. SP02 fails as before with number of
tasks set to 4: it fails trying to start task TA3 with RTEMS_TOO_MANY, as
before, though code inspection shows it should have enough tasks (assuming idle
and init tasks don't count). Increase number of tasks to 8 and it doesn't
fail, and it doesn't cause an exception (as it did with optimization on), but
nothing happens, it gets as far as:
*** TEST 2 ***
INIT - rtems_task_wake_after - yielding processor
PREEMPT - rtems_task_delete - deleting selfINIT - suspending TA2 while middle
task on a ready chain
and then when I break into the debugger it is in the idle thread. Note that
the task didn't exit (which would invoke bsp_reset), it's running but nothing
is happening.
(gdb) where
#0 0x000138b0 in mpc55xx_wait_for_interrupt ()
at ../../../../../.././phycore_mpc5554/lib/include/mpc55xx/mpc55xx.h:140
#1 0x000138d8 in bsp_idle_thread (arg=0x0)
at
../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/startup/idle-thread.c:30
#2 0x00043750 in _Thread_Handler ()
at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:188
#3 0x000436bc in _Thread_Handler_is_constructor_execution_required (
executing=0x7 <bsp_section_start_begin+7>)
at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:82
Backtrace stopped: frame did not save the PC
(gdb)
- Are there instructions on dumping RTEMS state (what's blocked on what) from
within GDB?
I went on to try sp03,4,5,6,7,... and all worked OK up to 7. sp07 didn't work
but the serial port output is pretty confused:
*** TEST 7 ***
rtems_extension_create - bad id pointer -- RTEMS_INVALID_ADDRESS
rtems_extension_create - bad name -- RTEMS_INVALID_NAME
rtems_extension_create - first one -- OK
rtems_extension_create - second one-- OK
rtems_extension_create -- RTEMS_TOO_MANY
rtems_extension_delete - second one -- OK
rtems_extension_delete - second one again -- RTEMS_INVALID_ID
rtems_extension_ident -- OK
rtems_extension_ident - bad name -- RTEMS_INVALID_NAME
rtems_extension_ident - bad name -- RTEMS_INVALID_ADDRESS
rtems_extension_create - harmless -- OK
TASK_CREATE - TA1 - created
TASK_CREATE<pause>
TA2 - rtems_task_get_note - get RTEMS_NOTEPAD_8 - current priority: -TA1 -
rtems_task_set_priority - get inid
T0ASK_CREATE -4 TA3 -
created
TASKTA1 - rtems_task_get_note - get RTEMS_NOTEPAD_8 - current priority: _TA2 -
rtems_task_set_note - set TA1'e
d
TASK_STARTTA1 - rtems_task_set_note - set TA2's RTEMS_NOTEPAD_8: -- TA1 -
star1ted
T-AS1K_START - TA
2 - started
TASK_STTA1 - rtems_task_set_priority - set TA2's priority: ATA2 -
rtems_task_set_priority - set TA1's prioritd
TASK_START - TA4 - s
tarted
rtems_task_set_priorityT-ASK_RESTAR1T - T
A3 - restarted
INIT - rtems_task_set_note - set my (id) RTEMS_NOTEPAD_4
rtems_task_set_priorityto TA1's priority: 04 FAILED (
FAILED -- expected (INIT - rtems_task_set_note - set my (SELF) RTEMS_NOTEPAD_4
RTEMS_SUCCESSFULto TA1's prioL
) got (INIT - rtems_task_set_note - set TA1's RTEMS_NOTEPAD_8 ) got (to TA1's
priority: 04RTEMS_INVALID_PRIORY
RTEMS_INVALID_PRIORITYINIT - rtems_task_se
- Is the serial port mixup output expected? I understand if it is, but if it's
unexpected I'd like to fix it.
- Are these "SPXX" tests run on a regular basis so I can see the status of other platforms? I
looked at what's linked to from "coverage results" on the RTEMS main page hoping to find the latest
runs but those tests haven't been run in a while - December 2012 for PowerPC. Are the tests in the
"sptests" directory run regularly, and are the results posted on-line?
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
