Status of phycore_mpc5554 with latest RTEMS and RSB built tools

Fri Feb 21 10:17:49 UTC 2014

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

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