Status of phycore_mpc5554 with latest RTEMS and RSB built tools

[Peter Dufault]

On Feb 15, 2014, at 09:56 , Peter Dufault <dufault at 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