Hello folks,
I'm using the TMS320C6424 in a system designed for a railway application,
my FW must include a DSP-self test, executed periodically in order to check that
everything is working as expected. Do you know the source code or an example of
C6424 self test? I need something similar to spra838a ("TMS320C6416 Power-On
Self Test") but suited to C6424.
Thanks in advance
Gio
_____________________________________
C6424 Power-On Self Test
Started by ●October 13, 2010
Reply by ●October 13, 20102010-10-13
Hello Gio,
On 10/13/2010 2:28 AM, presciutti_dgl2k wrote:
>
> Hello folks,
> I'm using the TMS320C6424 in a system designed for a railway
> application, my FW must include a DSP-self test, executed periodically
> in order to check that everything is working as expected. Do you know
> the source code or an example of C6424 self test? I need something
> similar to spra838a ("TMS320C6416 Power-On Self Test") but suited to
> C6424.
>
I must respectfully disagree with your approach.
I would suggest that you consider the following for your implementation.
1. You need to test 'what you are using'. If your system has a McBSP,
and it is not being used, I would not test it.
2. You need to test 'what you are using in the manner that you are using
it'. If you are using a McBSP that is setup in one of the dozens of
possible configurations, you want to use that configuration to test it.
3. If you accept #1 & #2, it would lead one to believe that the
application initialization parameters and drivers [or something 'highly
similar'] should be used to carry out the I/O portion of the test. If
the diagnostic requirement was properly considered [and respected] from
the beginning, some special hooks or parameters could have been included
in the SW and HW design.
4. You need to identify the constraints for your test software.
a. How many MIPS of headroom does your application have??
b. What are the realtime requirements?? How soon do you need to
respond to an interrupt??
c. Does the system contain any known or predictable 'idle time'??
5. Depending on your constraints, system capabilities and test
requirements, the test could be as "simple" as an additional low
priority task [it is seldom simple] or as complicated as to require
major application changes.
Think about your current app and what it does - then think about how you
can use what you have to test what you need to test. Real testing is
"very personal to the specific hardware and manner in which it is used.
mikedunn
>
> Thanks in advance
> Gio
On 10/13/2010 2:28 AM, presciutti_dgl2k wrote:
>
> Hello folks,
> I'm using the TMS320C6424 in a system designed for a railway
> application, my FW must include a DSP-self test, executed periodically
> in order to check that everything is working as expected. Do you know
> the source code or an example of C6424 self test? I need something
> similar to spra838a ("TMS320C6416 Power-On Self Test") but suited to
> C6424.
>
I must respectfully disagree with your approach.
I would suggest that you consider the following for your implementation.
1. You need to test 'what you are using'. If your system has a McBSP,
and it is not being used, I would not test it.
2. You need to test 'what you are using in the manner that you are using
it'. If you are using a McBSP that is setup in one of the dozens of
possible configurations, you want to use that configuration to test it.
3. If you accept #1 & #2, it would lead one to believe that the
application initialization parameters and drivers [or something 'highly
similar'] should be used to carry out the I/O portion of the test. If
the diagnostic requirement was properly considered [and respected] from
the beginning, some special hooks or parameters could have been included
in the SW and HW design.
4. You need to identify the constraints for your test software.
a. How many MIPS of headroom does your application have??
b. What are the realtime requirements?? How soon do you need to
respond to an interrupt??
c. Does the system contain any known or predictable 'idle time'??
5. Depending on your constraints, system capabilities and test
requirements, the test could be as "simple" as an additional low
priority task [it is seldom simple] or as complicated as to require
major application changes.
Think about your current app and what it does - then think about how you
can use what you have to test what you need to test. Real testing is
"very personal to the specific hardware and manner in which it is used.
mikedunn
>
> Thanks in advance
> Gio
Reply by ●October 13, 20102010-10-13
Gio,
There is a world of difference between a power-on BIT and a periodic BIT.
Most likely, any power-on BIT would not be of much use for the implementation of
a periodic BIT.
Also, a power-on BIT must perform several 'certification' activities and
hardware initialization activities that would be extremely disruptive if
performed during periodic BIT.
Most periodic BIT tasks must be implemented to perform a single BIT activity,
then exit, upon next execution, perform another single BIT activity, the exit,
etc. Where the periodic BIT task keeps 'state' information about where it is in
the list of periodic BIT activities.
A power-on bit is designed to run all its' BIT activities in one continuous pass
before passing control of the CPU to the application.
R. Williams
---------- Original Message -----------
From: mikedunn
To: presciutti_dgl2k
Cc: c...
Sent: Wed, 13 Oct 2010 11:02:40 -0500
Subject: Re: [c6x] C6424 Power-On Self Test
> Hello Gio,
>
> On 10/13/2010 2:28 AM, presciutti_dgl2k wrote:
> >
> > Hello folks,
> > I'm using the TMS320C6424 in a system designed for a railway
> > application, my FW must include a DSP-self test, executed periodically
> > in order to check that everything is working as expected. Do you know
> > the source code or an example of C6424 self test? I need something
> > similar to spra838a ("TMS320C6416 Power-On Self Test") but suited to
> > C6424.
> >
> I must respectfully disagree with your approach.
> I would suggest that you consider the following for your implementation.
> 1. You need to test 'what you are using'. If your system has a McBSP,
> and it is not being used, I would not test it.
> 2. You need to test 'what you are using in the manner that you are
> using it'. If you are using a McBSP that is setup in one of the dozens
> of possible configurations, you want to use that configuration to test
> it.
> 3. If you accept #1 & #2, it would lead one to believe that the
> application initialization parameters and drivers [or something
> 'highly similar'] should be used to carry out the I/O portion of the
> test. If the diagnostic requirement was properly considered [and
> respected] from the beginning, some special hooks or parameters could
> have been included in the SW and HW design.
> 4. You need to identify the constraints for your test software.
> a. How many MIPS of headroom does your application have??
> b. What are the realtime requirements?? How soon do you need to
> respond to an interrupt??
> c. Does the system contain any known or predictable 'idle time'??
> 5. Depending on your constraints, system capabilities and test
> requirements, the test could be as "simple" as an additional low
> priority task [it is seldom simple] or as complicated as to require
> major application changes.
>
> Think about your current app and what it does - then think about how
> you can use what you have to test what you need to test. Real testing
> is "very personal to the specific hardware and manner in which it is used.
>
> mikedunn
>
> >
> > Thanks in advance
> > Gio
> >
> >
------- End of Original Message -------
_____________________________________
There is a world of difference between a power-on BIT and a periodic BIT.
Most likely, any power-on BIT would not be of much use for the implementation of
a periodic BIT.
Also, a power-on BIT must perform several 'certification' activities and
hardware initialization activities that would be extremely disruptive if
performed during periodic BIT.
Most periodic BIT tasks must be implemented to perform a single BIT activity,
then exit, upon next execution, perform another single BIT activity, the exit,
etc. Where the periodic BIT task keeps 'state' information about where it is in
the list of periodic BIT activities.
A power-on bit is designed to run all its' BIT activities in one continuous pass
before passing control of the CPU to the application.
R. Williams
---------- Original Message -----------
From: mikedunn
To: presciutti_dgl2k
Cc: c...
Sent: Wed, 13 Oct 2010 11:02:40 -0500
Subject: Re: [c6x] C6424 Power-On Self Test
> Hello Gio,
>
> On 10/13/2010 2:28 AM, presciutti_dgl2k wrote:
> >
> > Hello folks,
> > I'm using the TMS320C6424 in a system designed for a railway
> > application, my FW must include a DSP-self test, executed periodically
> > in order to check that everything is working as expected. Do you know
> > the source code or an example of C6424 self test? I need something
> > similar to spra838a ("TMS320C6416 Power-On Self Test") but suited to
> > C6424.
> >
> I must respectfully disagree with your approach.
> I would suggest that you consider the following for your implementation.
> 1. You need to test 'what you are using'. If your system has a McBSP,
> and it is not being used, I would not test it.
> 2. You need to test 'what you are using in the manner that you are
> using it'. If you are using a McBSP that is setup in one of the dozens
> of possible configurations, you want to use that configuration to test
> it.
> 3. If you accept #1 & #2, it would lead one to believe that the
> application initialization parameters and drivers [or something
> 'highly similar'] should be used to carry out the I/O portion of the
> test. If the diagnostic requirement was properly considered [and
> respected] from the beginning, some special hooks or parameters could
> have been included in the SW and HW design.
> 4. You need to identify the constraints for your test software.
> a. How many MIPS of headroom does your application have??
> b. What are the realtime requirements?? How soon do you need to
> respond to an interrupt??
> c. Does the system contain any known or predictable 'idle time'??
> 5. Depending on your constraints, system capabilities and test
> requirements, the test could be as "simple" as an additional low
> priority task [it is seldom simple] or as complicated as to require
> major application changes.
>
> Think about your current app and what it does - then think about how
> you can use what you have to test what you need to test. Real testing
> is "very personal to the specific hardware and manner in which it is used.
>
> mikedunn
>
> >
> > Thanks in advance
> > Gio
> >
> >
------- End of Original Message -------
_____________________________________
Reply by ●October 14, 20102010-10-14
Mike,
Richard,
Thanks for your responses.
I'll give you some other information about my problem.
Working on railway applications, my FW must comply with safety regulations imposed by the EN50126 standard. For this reason I have strict constraint for the tests.
About spra838a, I am interested only to Core module Test, the other peripherals are tested with an approach similar to that proposed by Mike.
If I had Core Test similar to spra838a but suited to C6424, I'll divide the test into small tests
execute under interrupt service routines.
best regards,
Gio
--- In c..., "Richard Williams" wrote:
>
> Gio,
>
> There is a world of difference between a power-on BIT and a periodic BIT.
> Most likely, any power-on BIT would not be of much use for the implementation of
> a periodic BIT.
> Also, a power-on BIT must perform several 'certification' activities and
> hardware initialization activities that would be extremely disruptive if
> performed during periodic BIT.
>
> Most periodic BIT tasks must be implemented to perform a single BIT activity,
> then exit, upon next execution, perform another single BIT activity, the exit,
> etc. Where the periodic BIT task keeps 'state' information about where it is in
> the list of periodic BIT activities.
>
> A power-on bit is designed to run all its' BIT activities in one continuous pass
> before passing control of the CPU to the application.
>
> R. Williams
> ---------- Original Message -----------
> From: mikedunn
> To: presciutti_dgl2k
> Cc: c...
> Sent: Wed, 13 Oct 2010 11:02:40 -0500
> Subject: Re: [c6x] C6424 Power-On Self Test
>
> > Hello Gio,
> >
> > On 10/13/2010 2:28 AM, presciutti_dgl2k wrote:
> > >
> > > Hello folks,
> > > I'm using the TMS320C6424 in a system designed for a railway
> > > application, my FW must include a DSP-self test, executed periodically
> > > in order to check that everything is working as expected. Do you know
> > > the source code or an example of C6424 self test? I need something
> > > similar to spra838a ("TMS320C6416 Power-On Self Test") but suited to
> > > C6424.
> > >
> > I must respectfully disagree with your approach.
> > I would suggest that you consider the following for your implementation.
> > 1. You need to test 'what you are using'. If your system has a McBSP,
> > and it is not being used, I would not test it.
> > 2. You need to test 'what you are using in the manner that you are
> > using it'. If you are using a McBSP that is setup in one of the dozens
> > of possible configurations, you want to use that configuration to test
> > it.
> > 3. If you accept #1 & #2, it would lead one to believe that the
> > application initialization parameters and drivers [or something
> > 'highly similar'] should be used to carry out the I/O portion of the
> > test. If the diagnostic requirement was properly considered [and
> > respected] from the beginning, some special hooks or parameters could
> > have been included in the SW and HW design.
> > 4. You need to identify the constraints for your test software.
> > a. How many MIPS of headroom does your application have??
> > b. What are the realtime requirements?? How soon do you need to
> > respond to an interrupt??
> > c. Does the system contain any known or predictable 'idle time'??
> > 5. Depending on your constraints, system capabilities and test
> > requirements, the test could be as "simple" as an additional low
> > priority task [it is seldom simple] or as complicated as to require
> > major application changes.
> >
> > Think about your current app and what it does - then think about how
> > you can use what you have to test what you need to test. Real testing
> > is "very personal to the specific hardware and manner in which it is used.
> >
> > mikedunn
> >
> > >
> > > Thanks in advance
> > > Gio
> > >
> > >
> ------- End of Original Message -------
>
_____________________________________
Richard,
Thanks for your responses.
I'll give you some other information about my problem.
Working on railway applications, my FW must comply with safety regulations imposed by the EN50126 standard. For this reason I have strict constraint for the tests.
About spra838a, I am interested only to Core module Test, the other peripherals are tested with an approach similar to that proposed by Mike.
If I had Core Test similar to spra838a but suited to C6424, I'll divide the test into small tests
execute under interrupt service routines.
best regards,
Gio
--- In c..., "Richard Williams" wrote:
>
> Gio,
>
> There is a world of difference between a power-on BIT and a periodic BIT.
> Most likely, any power-on BIT would not be of much use for the implementation of
> a periodic BIT.
> Also, a power-on BIT must perform several 'certification' activities and
> hardware initialization activities that would be extremely disruptive if
> performed during periodic BIT.
>
> Most periodic BIT tasks must be implemented to perform a single BIT activity,
> then exit, upon next execution, perform another single BIT activity, the exit,
> etc. Where the periodic BIT task keeps 'state' information about where it is in
> the list of periodic BIT activities.
>
> A power-on bit is designed to run all its' BIT activities in one continuous pass
> before passing control of the CPU to the application.
>
> R. Williams
> ---------- Original Message -----------
> From: mikedunn
> To: presciutti_dgl2k
> Cc: c...
> Sent: Wed, 13 Oct 2010 11:02:40 -0500
> Subject: Re: [c6x] C6424 Power-On Self Test
>
> > Hello Gio,
> >
> > On 10/13/2010 2:28 AM, presciutti_dgl2k wrote:
> > >
> > > Hello folks,
> > > I'm using the TMS320C6424 in a system designed for a railway
> > > application, my FW must include a DSP-self test, executed periodically
> > > in order to check that everything is working as expected. Do you know
> > > the source code or an example of C6424 self test? I need something
> > > similar to spra838a ("TMS320C6416 Power-On Self Test") but suited to
> > > C6424.
> > >
> > I must respectfully disagree with your approach.
> > I would suggest that you consider the following for your implementation.
> > 1. You need to test 'what you are using'. If your system has a McBSP,
> > and it is not being used, I would not test it.
> > 2. You need to test 'what you are using in the manner that you are
> > using it'. If you are using a McBSP that is setup in one of the dozens
> > of possible configurations, you want to use that configuration to test
> > it.
> > 3. If you accept #1 & #2, it would lead one to believe that the
> > application initialization parameters and drivers [or something
> > 'highly similar'] should be used to carry out the I/O portion of the
> > test. If the diagnostic requirement was properly considered [and
> > respected] from the beginning, some special hooks or parameters could
> > have been included in the SW and HW design.
> > 4. You need to identify the constraints for your test software.
> > a. How many MIPS of headroom does your application have??
> > b. What are the realtime requirements?? How soon do you need to
> > respond to an interrupt??
> > c. Does the system contain any known or predictable 'idle time'??
> > 5. Depending on your constraints, system capabilities and test
> > requirements, the test could be as "simple" as an additional low
> > priority task [it is seldom simple] or as complicated as to require
> > major application changes.
> >
> > Think about your current app and what it does - then think about how
> > you can use what you have to test what you need to test. Real testing
> > is "very personal to the specific hardware and manner in which it is used.
> >
> > mikedunn
> >
> > >
> > > Thanks in advance
> > > Gio
> > >
> > >
> ------- End of Original Message -------
>
_____________________________________
