Hello all,
I'm working on the project whose objectives are
1) to establish communication via HPI between Atmel's At91M40008 host
processor and C6711D and
2) to boot DSP processor via HPI.
I've already tested communication and it works satisfactory but not
ideally. Not ideally because I have to read only in autoincrement mode
since read in fixed mode is unstable and thus incorrect in general. I
looked through errata documentation from TI and found that bug with HPI
read in fixed mode is known exception to C6711 functioning. The
workaround they offer is quite simple, namely, they advise to use HPI
read in autoincrement mode only. This helped, but still I have to read
the first address twice to get correct values.
HPI write was successful is both modes. It should be noted, however,
that packets exchanged between processors were rather small - not more
than 40 bytes.
Then I proceeded to testing booting via HPI. I write via HPI small DSP
pseudobootloader first (it configures PLL and McBSP) and then DSP
application itself. Then release DSP from reset. For now, I have the
following results - DSP application starts up correctly appr. 1 time out
of 10 attempts. The reason of unsuccessful attempts is that some words
sent by HPI write are incorrect. DSP bootloader size is appr. 2,5KB;
therefore just a few words out of appr. 600 are invalid. And it repeats
permanently. But why??? Why at some arbitrary moment HPI write is
incorrect? I believe I would be more optimistic if HPI write did not
work at all - in that case I would be sure that I missed something in
HPI setting, etc. But this random write fails disappoints me much more
because I have now idea why this happens. Maybe, some sort of hardware
problems?
Will be very grateful for any comments.
Thank you in advance.
With best regards,
MITA-TEKNIK
Taras Kournytskyi
Software developer
Contact details:
tku @mitaua.dk
Direct phone.: +380(32)2420435
Company details:
Mita-Teknik Ltd.
Kulparkivska 222a
79071 Lviv
Ukraine
HPI booting problem
Started by ●February 7, 2008
Reply by ●February 7, 20082008-02-07
Kurnytskyi-
> Im working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmels At91M40008 host processor and
> C6711D and
>
> 2) to boot DSP processor via HPI.
> Ive already tested communication and it works satisfactory but not ideally. Not
> ideally because I have to read only in autoincrement mode since read in fixed mode
> is unstable and thus incorrect in general. I looked through errata documentation
> from TI and found that bug with HPI read in fixed mode is known exception to C6711
> functioning. The workaround they offer is quite simple, namely, they advise to use
> HPI read in autoincrement mode only. This helped, but still I have to read the
> first address twice to get correct values.
>
> HPI write was successful is both modes. It should be noted, however, that packets
> exchanged between processors were rather small not more than 40 bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP application
> itself. Then release DSP from reset. For now, I have the following results DSP
> application starts up correctly appr. 1 time out of 10 attempts. The reason of
> unsuccessful attempts is that some words sent by HPI write are incorrect. DSP
> bootloader size is appr. 2,5KB; therefore just a few words out of appr. 600 are
> invalid. And it repeats permanently. But why??? Why at some arbitrary moment HPI
> write is incorrect? I believe I would be more optimistic if HPI write did not work
> at all in that case I would be sure that I missed something in HPI setting, etc.
> But this random write fails disappoints me much more because I have now idea why
> this happens. Maybe, some sort of hardware problems?
My suggestion is to back up a step and continue with HPI testing. You should be able
to do reliable "stress test" of HPI, using random combinations of read, write,
different addresses, tests that run overnight, etc.
In this way you will find the problem... maybe your Atmel code does not handle HRDY
or HDS correctly, etc. Or maybe there is still something in the errata that you have
not implemented or understood completely. Sometimes the errata can be an exercise in
"reading between the lines" to understand what is really the problem -- for example
something that TI does not want to admit openly.
Then move on to bootloader.
-Jeff
> Im working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmels At91M40008 host processor and
> C6711D and
>
> 2) to boot DSP processor via HPI.
> Ive already tested communication and it works satisfactory but not ideally. Not
> ideally because I have to read only in autoincrement mode since read in fixed mode
> is unstable and thus incorrect in general. I looked through errata documentation
> from TI and found that bug with HPI read in fixed mode is known exception to C6711
> functioning. The workaround they offer is quite simple, namely, they advise to use
> HPI read in autoincrement mode only. This helped, but still I have to read the
> first address twice to get correct values.
>
> HPI write was successful is both modes. It should be noted, however, that packets
> exchanged between processors were rather small not more than 40 bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP application
> itself. Then release DSP from reset. For now, I have the following results DSP
> application starts up correctly appr. 1 time out of 10 attempts. The reason of
> unsuccessful attempts is that some words sent by HPI write are incorrect. DSP
> bootloader size is appr. 2,5KB; therefore just a few words out of appr. 600 are
> invalid. And it repeats permanently. But why??? Why at some arbitrary moment HPI
> write is incorrect? I believe I would be more optimistic if HPI write did not work
> at all in that case I would be sure that I missed something in HPI setting, etc.
> But this random write fails disappoints me much more because I have now idea why
> this happens. Maybe, some sort of hardware problems?
My suggestion is to back up a step and continue with HPI testing. You should be able
to do reliable "stress test" of HPI, using random combinations of read, write,
different addresses, tests that run overnight, etc.
In this way you will find the problem... maybe your Atmel code does not handle HRDY
or HDS correctly, etc. Or maybe there is still something in the errata that you have
not implemented or understood completely. Sometimes the errata can be an exercise in
"reading between the lines" to understand what is really the problem -- for example
something that TI does not want to admit openly.
Then move on to bootloader.
-Jeff
Reply by ●February 8, 20082008-02-08
Hi Jeff,
Thank you for advice.
Regarding the "stress test", I've not carried out it yet, however tests
with randomly changing write/read addresses were successfully passed.
Moreover, if I write the same bootloader code (just to test HPI write)
in SDRAM address when DSP application is running (booted from its flash)
then everything is OK - no HPI write fails. Besides, I've also noticed
that HPI reads fail during HPI booting. Therefore, it can be stated with
a high probability that something different happens during HPI write
when DSP is in reset and when it is running.
Regards,
Taras
_____
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Thursday, February 07, 2008 11:38 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Kurnytskyi-
I'm working on the project whose objectives are
1) to establish communication via HPI between Atmel's At91M40008 host
processor and C6711D and
2) to boot DSP processor via HPI.
I've already tested communication and it works satisfactory but not
ideally. Not ideally because I have to read only in autoincrement mode
since read in fixed mode is unstable and thus incorrect in general. I
looked through errata documentation from TI and found that bug with HPI
read in fixed mode is known exception to C6711 functioning. The
workaround they offer is quite simple, namely, they advise to use HPI
read in autoincrement mode only. This helped, but still I have to read
the first address twice to get correct values.
HPI write was successful is both modes. It should be noted, however,
that packets exchanged between processors were rather small - not more
than 40 bytes.
Then I proceeded to testing booting via HPI. I write via HPI small DSP
pseudobootloader first (it configures PLL and McBSP) and then DSP
application itself. Then release DSP from reset. For now, I have the
following results - DSP application starts up correctly appr. 1 time out
of 10 attempts. The reason of unsuccessful attempts is that some words
sent by HPI write are incorrect. DSP bootloader size is appr. 2,5KB;
therefore just a few words out of appr. 600 are invalid. And it repeats
permanently. But why??? Why at some arbitrary moment HPI write is
incorrect? I believe I would be more optimistic if HPI write did not
work at all - in that case I would be sure that I missed something in
HPI setting, etc. But this random write fails disappoints me much more
because I have now idea why this happens. Maybe, some sort of hardware
problems?
My suggestion is to back up a step and continue with HPI testing. You
should be able to do reliable "stress test" of HPI, using random
combinations of read, write, different addresses, tests that run
overnight, etc.
In this way you will find the problem... maybe your Atmel code does not
handle HRDY or HDS correctly, etc. Or maybe there is still something in
the errata that you have not implemented or understood completely.
Sometimes the errata can be an exercise in "reading between the lines"
to understand what is really the problem -- for example something that
TI does not want to admit openly.
Then move on to bootloader.
-Jeff
Thank you for advice.
Regarding the "stress test", I've not carried out it yet, however tests
with randomly changing write/read addresses were successfully passed.
Moreover, if I write the same bootloader code (just to test HPI write)
in SDRAM address when DSP application is running (booted from its flash)
then everything is OK - no HPI write fails. Besides, I've also noticed
that HPI reads fail during HPI booting. Therefore, it can be stated with
a high probability that something different happens during HPI write
when DSP is in reset and when it is running.
Regards,
Taras
_____
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Thursday, February 07, 2008 11:38 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Kurnytskyi-
I'm working on the project whose objectives are
1) to establish communication via HPI between Atmel's At91M40008 host
processor and C6711D and
2) to boot DSP processor via HPI.
I've already tested communication and it works satisfactory but not
ideally. Not ideally because I have to read only in autoincrement mode
since read in fixed mode is unstable and thus incorrect in general. I
looked through errata documentation from TI and found that bug with HPI
read in fixed mode is known exception to C6711 functioning. The
workaround they offer is quite simple, namely, they advise to use HPI
read in autoincrement mode only. This helped, but still I have to read
the first address twice to get correct values.
HPI write was successful is both modes. It should be noted, however,
that packets exchanged between processors were rather small - not more
than 40 bytes.
Then I proceeded to testing booting via HPI. I write via HPI small DSP
pseudobootloader first (it configures PLL and McBSP) and then DSP
application itself. Then release DSP from reset. For now, I have the
following results - DSP application starts up correctly appr. 1 time out
of 10 attempts. The reason of unsuccessful attempts is that some words
sent by HPI write are incorrect. DSP bootloader size is appr. 2,5KB;
therefore just a few words out of appr. 600 are invalid. And it repeats
permanently. But why??? Why at some arbitrary moment HPI write is
incorrect? I believe I would be more optimistic if HPI write did not
work at all - in that case I would be sure that I missed something in
HPI setting, etc. But this random write fails disappoints me much more
because I have now idea why this happens. Maybe, some sort of hardware
problems?
My suggestion is to back up a step and continue with HPI testing. You
should be able to do reliable "stress test" of HPI, using random
combinations of read, write, different addresses, tests that run
overnight, etc.
In this way you will find the problem... maybe your Atmel code does not
handle HRDY or HDS correctly, etc. Or maybe there is still something in
the errata that you have not implemented or understood completely.
Sometimes the errata can be an exercise in "reading between the lines"
to understand what is really the problem -- for example something that
TI does not want to admit openly.
Then move on to bootloader.
-Jeff
Reply by ●February 8, 20082008-02-08
Taras,
On Feb 8, 2008 10:21 AM, Kurnytskyi Taras wrote:
> Hi Jeff,
> Thank you for advice.
>
> Regarding the "stress test", I've not carried out it yet, however tests with
> randomly changing write/read addresses were successfully passed. Moreover,
> if I write the same bootloader code (just to test HPI write) in SDRAM
> address when DSP application is running (booted from its flash) then
> everything is OK no HPI write fails. Besides, I've also noticed that HPI
> reads fail during HPI booting.
I believe that 'HPI boot mode' is write only [wrt the host] until you
issue DSPINT.
>Therefore, it can be stated with a high
> probability that something different happens during HPI write when DSP is in
> reset and when it is running.
When you say that 'the DSP is in reset', are you referring to the
state during HPI boot or are you applying an external reset during HPI
boot??
mikedunn
>
> Regards,
> Taras
> ______________________________
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Thursday, February 07, 2008 11:38 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Kurnytskyi-
>
> I'm working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmel's At91M40008 host
> processor and C6711D and
>
> 2) to boot DSP processor via HPI.
>
> I've already tested communication and it works satisfactory but not ideally.
> Not ideally because I have to read only in autoincrement mode since read in
> fixed mode is unstable and thus incorrect in general. I looked through
> errata documentation from TI and found that bug with HPI read in fixed mode
> is known exception to C6711 functioning. The workaround they offer is quite
> simple, namely, they advise to use HPI read in autoincrement mode only. This
> helped, but still I have to read the first address twice to get correct
> values.
>
> HPI write was successful is both modes. It should be noted, however, that
> packets exchanged between processors were rather small not more than 40
> bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP
> application itself. Then release DSP from reset. For now, I have the
> following results DSP application starts up correctly appr. 1 time out of
> 10 attempts. The reason of unsuccessful attempts is that some words sent by
> HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore just
> a few words out of appr. 600 are invalid. And it repeats permanently. But
> why??? Why at some arbitrary moment HPI write is incorrect? I believe I
> would be more optimistic if HPI write did not work at all in that case I
> would be sure that I missed something in HPI setting, etc. But this random
> write fails disappoints me much more because I have now idea why this
> happens. Maybe, some sort of hardware problems?
> My suggestion is to back up a step and continue with HPI testing. You
> should be able to do reliable "stress test" of HPI, using random
> combinations of read, write, different addresses, tests that run overnight,
> etc.
>
> In this way you will find the problem... maybe your Atmel code does not
> handle HRDY or HDS correctly, etc. Or maybe there is still something in the
> errata that you have not implemented or understood completely. Sometimes
> the errata can be an exercise in "reading between the lines" to understand
> what is really the problem -- for example something that TI does not want to
> admit openly.
>
> Then move on to bootloader.
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
On Feb 8, 2008 10:21 AM, Kurnytskyi Taras wrote:
> Hi Jeff,
> Thank you for advice.
>
> Regarding the "stress test", I've not carried out it yet, however tests with
> randomly changing write/read addresses were successfully passed. Moreover,
> if I write the same bootloader code (just to test HPI write) in SDRAM
> address when DSP application is running (booted from its flash) then
> everything is OK no HPI write fails. Besides, I've also noticed that HPI
> reads fail during HPI booting.
I believe that 'HPI boot mode' is write only [wrt the host] until you
issue DSPINT.
>Therefore, it can be stated with a high
> probability that something different happens during HPI write when DSP is in
> reset and when it is running.
When you say that 'the DSP is in reset', are you referring to the
state during HPI boot or are you applying an external reset during HPI
boot??
mikedunn
>
> Regards,
> Taras
> ______________________________
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Thursday, February 07, 2008 11:38 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Kurnytskyi-
>
> I'm working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmel's At91M40008 host
> processor and C6711D and
>
> 2) to boot DSP processor via HPI.
>
> I've already tested communication and it works satisfactory but not ideally.
> Not ideally because I have to read only in autoincrement mode since read in
> fixed mode is unstable and thus incorrect in general. I looked through
> errata documentation from TI and found that bug with HPI read in fixed mode
> is known exception to C6711 functioning. The workaround they offer is quite
> simple, namely, they advise to use HPI read in autoincrement mode only. This
> helped, but still I have to read the first address twice to get correct
> values.
>
> HPI write was successful is both modes. It should be noted, however, that
> packets exchanged between processors were rather small not more than 40
> bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP
> application itself. Then release DSP from reset. For now, I have the
> following results DSP application starts up correctly appr. 1 time out of
> 10 attempts. The reason of unsuccessful attempts is that some words sent by
> HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore just
> a few words out of appr. 600 are invalid. And it repeats permanently. But
> why??? Why at some arbitrary moment HPI write is incorrect? I believe I
> would be more optimistic if HPI write did not work at all in that case I
> would be sure that I missed something in HPI setting, etc. But this random
> write fails disappoints me much more because I have now idea why this
> happens. Maybe, some sort of hardware problems?
> My suggestion is to back up a step and continue with HPI testing. You
> should be able to do reliable "stress test" of HPI, using random
> combinations of read, write, different addresses, tests that run overnight,
> etc.
>
> In this way you will find the problem... maybe your Atmel code does not
> handle HRDY or HDS correctly, etc. Or maybe there is still something in the
> errata that you have not implemented or understood completely. Sometimes
> the errata can be an exercise in "reading between the lines" to understand
> what is really the problem -- for example something that TI does not want to
> admit openly.
>
> Then move on to bootloader.
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by ●February 8, 20082008-02-08
Mike-
> On Feb 8, 2008 10:21 AM, Kurnytskyi Taras wrote:
> > Hi Jeff,
> > Thank you for advice.
> >
> > Regarding the "stress test", I've not carried out it yet, however tests with
> > randomly changing write/read addresses were successfully passed. Moreover,
> > if I write the same bootloader code (just to test HPI write) in SDRAM
> > address when DSP application is running (booted from its flash) then
> > everything is OK no HPI write fails. Besides, I've also noticed that HPI
> > reads fail during HPI booting.
>
> I believe that 'HPI boot mode' is write only [wrt the host] until you
> issue DSPINT.
The C6711D data sheet indicates the host can read/write DSP mem while the CPU is
"stalled" (before DSPINT bit is set).
-Jeff
> >Therefore, it can be stated with a high
> > probability that something different happens during HPI write when DSP is in
> > reset and when it is running.
>
> When you say that 'the DSP is in reset', are you referring to the
> state during HPI boot or are you applying an external reset during HPI
> boot??
>
> mikedunn
> >
> > Regards,
> > Taras
> > ______________________________
> >
> >
> > From: Jeff Brower [mailto:j...@signalogic.com]
> > Sent: Thursday, February 07, 2008 11:38 PM
> > To: Kurnytskyi Taras
> > Cc: c...
> > Subject: Re: [c6x] HPI booting problem
> >
> > Kurnytskyi-
> >
> > I'm working on the project whose objectives are
> >
> > 1) to establish communication via HPI between Atmel's At91M40008 host
> > processor and C6711D and
> >
> > 2) to boot DSP processor via HPI.
> >
> > I've already tested communication and it works satisfactory but not ideally.
> > Not ideally because I have to read only in autoincrement mode since read in
> > fixed mode is unstable and thus incorrect in general. I looked through
> > errata documentation from TI and found that bug with HPI read in fixed mode
> > is known exception to C6711 functioning. The workaround they offer is quite
> > simple, namely, they advise to use HPI read in autoincrement mode only. This
> > helped, but still I have to read the first address twice to get correct
> > values.
> >
> > HPI write was successful is both modes. It should be noted, however, that
> > packets exchanged between processors were rather small not more than 40
> > bytes.
> >
> > Then I proceeded to testing booting via HPI. I write via HPI small DSP
> > pseudobootloader first (it configures PLL and McBSP) and then DSP
> > application itself. Then release DSP from reset. For now, I have the
> > following results DSP application starts up correctly appr. 1 time out of
> > 10 attempts. The reason of unsuccessful attempts is that some words sent by
> > HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore just
> > a few words out of appr. 600 are invalid. And it repeats permanently. But
> > why??? Why at some arbitrary moment HPI write is incorrect? I believe I
> > would be more optimistic if HPI write did not work at all in that case I
> > would be sure that I missed something in HPI setting, etc. But this random
> > write fails disappoints me much more because I have now idea why this
> > happens. Maybe, some sort of hardware problems?
> >
> >
> >
> >
> > My suggestion is to back up a step and continue with HPI testing. You
> > should be able to do reliable "stress test" of HPI, using random
> > combinations of read, write, different addresses, tests that run overnight,
> > etc.
> >
> > In this way you will find the problem... maybe your Atmel code does not
> > handle HRDY or HDS correctly, etc. Or maybe there is still something in the
> > errata that you have not implemented or understood completely. Sometimes
> > the errata can be an exercise in "reading between the lines" to understand
> > what is really the problem -- for example something that TI does not want to
> > admit openly.
> >
> > Then move on to bootloader.
> >
> > -Jeff
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
> On Feb 8, 2008 10:21 AM, Kurnytskyi Taras wrote:
> > Hi Jeff,
> > Thank you for advice.
> >
> > Regarding the "stress test", I've not carried out it yet, however tests with
> > randomly changing write/read addresses were successfully passed. Moreover,
> > if I write the same bootloader code (just to test HPI write) in SDRAM
> > address when DSP application is running (booted from its flash) then
> > everything is OK no HPI write fails. Besides, I've also noticed that HPI
> > reads fail during HPI booting.
>
> I believe that 'HPI boot mode' is write only [wrt the host] until you
> issue DSPINT.
The C6711D data sheet indicates the host can read/write DSP mem while the CPU is
"stalled" (before DSPINT bit is set).
-Jeff
> >Therefore, it can be stated with a high
> > probability that something different happens during HPI write when DSP is in
> > reset and when it is running.
>
> When you say that 'the DSP is in reset', are you referring to the
> state during HPI boot or are you applying an external reset during HPI
> boot??
>
> mikedunn
> >
> > Regards,
> > Taras
> > ______________________________
> >
> >
> > From: Jeff Brower [mailto:j...@signalogic.com]
> > Sent: Thursday, February 07, 2008 11:38 PM
> > To: Kurnytskyi Taras
> > Cc: c...
> > Subject: Re: [c6x] HPI booting problem
> >
> > Kurnytskyi-
> >
> > I'm working on the project whose objectives are
> >
> > 1) to establish communication via HPI between Atmel's At91M40008 host
> > processor and C6711D and
> >
> > 2) to boot DSP processor via HPI.
> >
> > I've already tested communication and it works satisfactory but not ideally.
> > Not ideally because I have to read only in autoincrement mode since read in
> > fixed mode is unstable and thus incorrect in general. I looked through
> > errata documentation from TI and found that bug with HPI read in fixed mode
> > is known exception to C6711 functioning. The workaround they offer is quite
> > simple, namely, they advise to use HPI read in autoincrement mode only. This
> > helped, but still I have to read the first address twice to get correct
> > values.
> >
> > HPI write was successful is both modes. It should be noted, however, that
> > packets exchanged between processors were rather small not more than 40
> > bytes.
> >
> > Then I proceeded to testing booting via HPI. I write via HPI small DSP
> > pseudobootloader first (it configures PLL and McBSP) and then DSP
> > application itself. Then release DSP from reset. For now, I have the
> > following results DSP application starts up correctly appr. 1 time out of
> > 10 attempts. The reason of unsuccessful attempts is that some words sent by
> > HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore just
> > a few words out of appr. 600 are invalid. And it repeats permanently. But
> > why??? Why at some arbitrary moment HPI write is incorrect? I believe I
> > would be more optimistic if HPI write did not work at all in that case I
> > would be sure that I missed something in HPI setting, etc. But this random
> > write fails disappoints me much more because I have now idea why this
> > happens. Maybe, some sort of hardware problems?
> >
> >
> >
> >
> > My suggestion is to back up a step and continue with HPI testing. You
> > should be able to do reliable "stress test" of HPI, using random
> > combinations of read, write, different addresses, tests that run overnight,
> > etc.
> >
> > In this way you will find the problem... maybe your Atmel code does not
> > handle HRDY or HDS correctly, etc. Or maybe there is still something in the
> > errata that you have not implemented or understood completely. Sometimes
> > the errata can be an exercise in "reading between the lines" to understand
> > what is really the problem -- for example something that TI does not want to
> > admit openly.
> >
> > Then move on to bootloader.
> >
> > -Jeff
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by ●February 8, 20082008-02-08
Thank you for reply, Michael,
By saying "DSP is in reset" I refer to the state during HPI boot, that
is, when DSP core is held in reset while peripherals are not in reset. I
send code by means of HPI write during that state. And I get this state
by setting signal (actually, 0) on responsible DSP pin. When all code
(bootloader and appl.) is written to DSP memory I issue DSPINT.
Regards,
Taras.
-----Original Message-----
From: Michael Dunn [mailto:m...@gmail.com]
Sent: Friday, February 08, 2008 7:10 PM
To: Kurnytskyi Taras
Cc: Jeff Brower; c...
Subject: Re: [c6x] HPI booting problem
Taras,
On Feb 8, 2008 10:21 AM, Kurnytskyi Taras wrote:
> Hi Jeff,
> Thank you for advice.
>
> Regarding the "stress test", I've not carried out it yet, however
tests with
> randomly changing write/read addresses were successfully passed.
Moreover,
> if I write the same bootloader code (just to test HPI write) in SDRAM
> address when DSP application is running (booted from its flash) then
> everything is OK - no HPI write fails. Besides, I've also noticed that
HPI
> reads fail during HPI booting.
I believe that 'HPI boot mode' is write only [wrt the host] until you
issue DSPINT.
>Therefore, it can be stated with a high
> probability that something different happens during HPI write when DSP
is in
> reset and when it is running.
When you say that 'the DSP is in reset', are you referring to the
state during HPI boot or are you applying an external reset during HPI
boot??
mikedunn
>
> Regards,
> Taras
> ______________________________
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Thursday, February 07, 2008 11:38 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Kurnytskyi-
>
> I'm working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmel's At91M40008 host
> processor and C6711D and
>
> 2) to boot DSP processor via HPI.
>
> I've already tested communication and it works satisfactory but not
ideally.
> Not ideally because I have to read only in autoincrement mode since
read in
> fixed mode is unstable and thus incorrect in general. I looked through
> errata documentation from TI and found that bug with HPI read in fixed
mode
> is known exception to C6711 functioning. The workaround they offer is
quite
> simple, namely, they advise to use HPI read in autoincrement mode
only. This
> helped, but still I have to read the first address twice to get
correct
> values.
>
> HPI write was successful is both modes. It should be noted, however,
that
> packets exchanged between processors were rather small - not more than
40
> bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP
> application itself. Then release DSP from reset. For now, I have the
> following results - DSP application starts up correctly appr. 1 time
out of
> 10 attempts. The reason of unsuccessful attempts is that some words
sent by
> HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore
just
> a few words out of appr. 600 are invalid. And it repeats permanently.
But
> why??? Why at some arbitrary moment HPI write is incorrect? I believe
I
> would be more optimistic if HPI write did not work at all - in that
case I
> would be sure that I missed something in HPI setting, etc. But this
random
> write fails disappoints me much more because I have now idea why this
> happens. Maybe, some sort of hardware problems?
> My suggestion is to back up a step and continue with HPI testing.
You
> should be able to do reliable "stress test" of HPI, using random
> combinations of read, write, different addresses, tests that run
overnight,
> etc.
>
> In this way you will find the problem... maybe your Atmel code does
not
> handle HRDY or HDS correctly, etc. Or maybe there is still something
in the
> errata that you have not implemented or understood completely.
Sometimes
> the errata can be an exercise in "reading between the lines" to
understand
> what is really the problem -- for example something that TI does not
want to
> admit openly.
>
> Then move on to bootloader.
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
By saying "DSP is in reset" I refer to the state during HPI boot, that
is, when DSP core is held in reset while peripherals are not in reset. I
send code by means of HPI write during that state. And I get this state
by setting signal (actually, 0) on responsible DSP pin. When all code
(bootloader and appl.) is written to DSP memory I issue DSPINT.
Regards,
Taras.
-----Original Message-----
From: Michael Dunn [mailto:m...@gmail.com]
Sent: Friday, February 08, 2008 7:10 PM
To: Kurnytskyi Taras
Cc: Jeff Brower; c...
Subject: Re: [c6x] HPI booting problem
Taras,
On Feb 8, 2008 10:21 AM, Kurnytskyi Taras wrote:
> Hi Jeff,
> Thank you for advice.
>
> Regarding the "stress test", I've not carried out it yet, however
tests with
> randomly changing write/read addresses were successfully passed.
Moreover,
> if I write the same bootloader code (just to test HPI write) in SDRAM
> address when DSP application is running (booted from its flash) then
> everything is OK - no HPI write fails. Besides, I've also noticed that
HPI
> reads fail during HPI booting.
I believe that 'HPI boot mode' is write only [wrt the host] until you
issue DSPINT.
>Therefore, it can be stated with a high
> probability that something different happens during HPI write when DSP
is in
> reset and when it is running.
When you say that 'the DSP is in reset', are you referring to the
state during HPI boot or are you applying an external reset during HPI
boot??
mikedunn
>
> Regards,
> Taras
> ______________________________
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Thursday, February 07, 2008 11:38 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Kurnytskyi-
>
> I'm working on the project whose objectives are
>
> 1) to establish communication via HPI between Atmel's At91M40008 host
> processor and C6711D and
>
> 2) to boot DSP processor via HPI.
>
> I've already tested communication and it works satisfactory but not
ideally.
> Not ideally because I have to read only in autoincrement mode since
read in
> fixed mode is unstable and thus incorrect in general. I looked through
> errata documentation from TI and found that bug with HPI read in fixed
mode
> is known exception to C6711 functioning. The workaround they offer is
quite
> simple, namely, they advise to use HPI read in autoincrement mode
only. This
> helped, but still I have to read the first address twice to get
correct
> values.
>
> HPI write was successful is both modes. It should be noted, however,
that
> packets exchanged between processors were rather small - not more than
40
> bytes.
>
> Then I proceeded to testing booting via HPI. I write via HPI small DSP
> pseudobootloader first (it configures PLL and McBSP) and then DSP
> application itself. Then release DSP from reset. For now, I have the
> following results - DSP application starts up correctly appr. 1 time
out of
> 10 attempts. The reason of unsuccessful attempts is that some words
sent by
> HPI write are incorrect. DSP bootloader size is appr. 2,5KB; therefore
just
> a few words out of appr. 600 are invalid. And it repeats permanently.
But
> why??? Why at some arbitrary moment HPI write is incorrect? I believe
I
> would be more optimistic if HPI write did not work at all - in that
case I
> would be sure that I missed something in HPI setting, etc. But this
random
> write fails disappoints me much more because I have now idea why this
> happens. Maybe, some sort of hardware problems?
> My suggestion is to back up a step and continue with HPI testing.
You
> should be able to do reliable "stress test" of HPI, using random
> combinations of read, write, different addresses, tests that run
overnight,
> etc.
>
> In this way you will find the problem... maybe your Atmel code does
not
> handle HRDY or HDS correctly, etc. Or maybe there is still something
in the
> errata that you have not implemented or understood completely.
Sometimes
> the errata can be an exercise in "reading between the lines" to
understand
> what is really the problem -- for example something that TI does not
want to
> admit openly.
>
> Then move on to bootloader.
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●February 12, 20082008-02-12
Hi,
Further investigations showed that indeed there is a difference between
HPI behavior when DSP is in "internal" reset (released from external
reset, but "stalled" waiting for DSPINT bit) and DSP is normally running
(after DSPINT bit is set). Therefore, if I now send DSP appl. code after
DSPINT bit is set then everything is OK - appl. code is sent correctly
and it is running! However, a little problem is still annoying because
my small bootloader is still sent during DSP internal reset and
sometimes some words get corrupted. Nevertheless, this is a solution for
a moment.
If somebody met such problem in the past or was anyhow concerned with
this please be so kind to let me know.
Thank you in advance.
Taras.
Further investigations showed that indeed there is a difference between
HPI behavior when DSP is in "internal" reset (released from external
reset, but "stalled" waiting for DSPINT bit) and DSP is normally running
(after DSPINT bit is set). Therefore, if I now send DSP appl. code after
DSPINT bit is set then everything is OK - appl. code is sent correctly
and it is running! However, a little problem is still annoying because
my small bootloader is still sent during DSP internal reset and
sometimes some words get corrupted. Nevertheless, this is a solution for
a moment.
If somebody met such problem in the past or was anyhow concerned with
this please be so kind to let me know.
Thank you in advance.
Taras.
Reply by ●February 12, 20082008-02-12
Taras-
> Further investigations showed that indeed there is a difference between HPI
> behavior when DSP is in "internal" reset (released from external reset, but
> "stalled" waiting for DSPINT bit) and DSP is normally running (after DSPINT bit is
> set). Therefore, if I now send DSP appl. code after DSPINT bit is set then
> everything is OK appl. code is sent correctly and it is running! However, a
> little problem is still annoying because my small bootloader is still sent during
> DSP internal reset and sometimes some words get corrupted. Nevertheless, this is a
> solution for a moment.
> If somebody met such problem in the past or was anyhow concerned with this please
> be so kind to let me know.
Some suggestions:
1) Minimize code sent prior to releasing the stall. All that's really needed is a
2-instruction loop that does nothing . Once the chip is running you can load any
other code and go from there.
2) During the stall period treat HPI more carefully. Slow down the rate of access,
read back each word written, re-try until data is correct.
-Jeff
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
> Further investigations showed that indeed there is a difference between HPI
> behavior when DSP is in "internal" reset (released from external reset, but
> "stalled" waiting for DSPINT bit) and DSP is normally running (after DSPINT bit is
> set). Therefore, if I now send DSP appl. code after DSPINT bit is set then
> everything is OK appl. code is sent correctly and it is running! However, a
> little problem is still annoying because my small bootloader is still sent during
> DSP internal reset and sometimes some words get corrupted. Nevertheless, this is a
> solution for a moment.
> If somebody met such problem in the past or was anyhow concerned with this please
> be so kind to let me know.
Some suggestions:
1) Minimize code sent prior to releasing the stall. All that's really needed is a
2-instruction loop that does nothing . Once the chip is running you can load any
other code and go from there.
2) During the stall period treat HPI more carefully. Slow down the rate of access,
read back each word written, re-try until data is correct.
-Jeff
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by ●February 15, 20082008-02-15
Eliezer-
I am not the OP. I believe that Taras is using 6711D.
-Jeff
PS. Please post to the group, not to me.
Eliezer wrote:
> HiI am just in the phase of operating the HPI on the C6424 through an ALTERA FPGA
> as the host, in two stages of course:- no boot mode ( host write successfull now
> read testing ...)- boot modeIs your discussions concerns the HPI on the C6424 as
> wellThanks Eliezer Tofach
> ------------
> From: c... [mailto:c...] On Behalf Of Jeff Brower
> Sent: Tuesday, February 12, 2008 9:02 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: [!! SPAM] Re: [c6x] HPI booting problem
>
> Taras-
>
> > Further investigations showed that indeed there is a difference between HPI
> > behavior when DSP is in "internal" reset (released from external reset, but
> > "stalled" waiting for DSPINT bit) and DSP is normally running (after DSPINT bit
> is
> > set). Therefore, if I now send DSP appl. code after DSPINT bit is set then
> > everything is OK appl. code is sent correctly and it is running! However, a
> > little problem is still annoying because my small bootloader is still sent during
>
> > DSP internal reset and sometimes some words get corrupted. Nevertheless, this is
> a
> > solution for a moment.
> > If somebody met such problem in the past or was anyhow concerned with this please
>
> > be so kind to let me know.
>
> Some suggestions:
>
> 1) Minimize code sent prior to releasing the stall. All that's really needed is a
> 2-instruction loop that does nothing . Once the chip is running you can load any
> other code and go from there.
>
> 2) During the stall period treat HPI more carefully. Slow down the rate of access,
> read back each word written, re-try until data is correct.
>
> -Jeff
>
I am not the OP. I believe that Taras is using 6711D.
-Jeff
PS. Please post to the group, not to me.
Eliezer wrote:
> HiI am just in the phase of operating the HPI on the C6424 through an ALTERA FPGA
> as the host, in two stages of course:- no boot mode ( host write successfull now
> read testing ...)- boot modeIs your discussions concerns the HPI on the C6424 as
> wellThanks Eliezer Tofach
> ------------
> From: c... [mailto:c...] On Behalf Of Jeff Brower
> Sent: Tuesday, February 12, 2008 9:02 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: [!! SPAM] Re: [c6x] HPI booting problem
>
> Taras-
>
> > Further investigations showed that indeed there is a difference between HPI
> > behavior when DSP is in "internal" reset (released from external reset, but
> > "stalled" waiting for DSPINT bit) and DSP is normally running (after DSPINT bit
> is
> > set). Therefore, if I now send DSP appl. code after DSPINT bit is set then
> > everything is OK appl. code is sent correctly and it is running! However, a
> > little problem is still annoying because my small bootloader is still sent during
>
> > DSP internal reset and sometimes some words get corrupted. Nevertheless, this is
> a
> > solution for a moment.
> > If somebody met such problem in the past or was anyhow concerned with this please
>
> > be so kind to let me know.
>
> Some suggestions:
>
> 1) Minimize code sent prior to releasing the stall. All that's really needed is a
> 2-instruction loop that does nothing . Once the chip is running you can load any
> other code and go from there.
>
> 2) During the stall period treat HPI more carefully. Slow down the rate of access,
> read back each word written, re-try until data is correct.
>
> -Jeff
>
Reply by ●February 21, 20082008-02-21
Jeff,
Thank you very much for your suggestions. I checked it again and
conclusion remains the same - there is clearly a difference in HPI
behavior when DSP is stalled in internal reset waiting for DSPINT bit
and when it is normally running.
I did as you adviced and tried to read (during stalled state) on the
host side the values (EMIF registers) which have just been written via
HPI. And result was stunning - HPI read in this stalled state is much
worse than HPI write. While HPI write fails appr. once on 100 words, the
rate of HPI read fails gets 50%. And what is interesting, the errors are
very similar to those met previously when I read in fixed mode, that is,
one read lag. But then I coped with it by using read in autoincrement
mode. In stalled state this "trick" does not work:).
As this point I believe that this is due to some hardware problems. But,
unfortunately, I cannot check it myself due to lack of special devices
needed. I hope my colleagues with assist me with this and I'll let you
know their conclusions.
By the way, how can I slow down the rate of access?
-----Original Message-----
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Tuesday, February 12, 2008 9:02 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Taras-
> Further investigations showed that indeed there is a difference
between HPI
> behavior when DSP is in "internal" reset (released from external
reset, but
> "stalled" waiting for DSPINT bit) and DSP is normally running (after
DSPINT bit is
> set). Therefore, if I now send DSP appl. code after DSPINT bit is set
then
> everything is OK - appl. code is sent correctly and it is running!
However, a
> little problem is still annoying because my small bootloader is still
sent during
> DSP internal reset and sometimes some words get corrupted.
Nevertheless, this is a
> solution for a moment.
> If somebody met such problem in the past or was anyhow concerned with
this please
> be so kind to let me know.
Some suggestions:
1) Minimize code sent prior to releasing the stall. All that's really
needed is a
2-instruction loop that does nothing . Once the chip is running you can
load any
other code and go from there.
2) During the stall period treat HPI more carefully. Slow down the rate
of access,
read back each word written, re-try until data is correct.
-Jeff
Thank you very much for your suggestions. I checked it again and
conclusion remains the same - there is clearly a difference in HPI
behavior when DSP is stalled in internal reset waiting for DSPINT bit
and when it is normally running.
I did as you adviced and tried to read (during stalled state) on the
host side the values (EMIF registers) which have just been written via
HPI. And result was stunning - HPI read in this stalled state is much
worse than HPI write. While HPI write fails appr. once on 100 words, the
rate of HPI read fails gets 50%. And what is interesting, the errors are
very similar to those met previously when I read in fixed mode, that is,
one read lag. But then I coped with it by using read in autoincrement
mode. In stalled state this "trick" does not work:).
As this point I believe that this is due to some hardware problems. But,
unfortunately, I cannot check it myself due to lack of special devices
needed. I hope my colleagues with assist me with this and I'll let you
know their conclusions.
By the way, how can I slow down the rate of access?
-----Original Message-----
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Tuesday, February 12, 2008 9:02 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Taras-
> Further investigations showed that indeed there is a difference
between HPI
> behavior when DSP is in "internal" reset (released from external
reset, but
> "stalled" waiting for DSPINT bit) and DSP is normally running (after
DSPINT bit is
> set). Therefore, if I now send DSP appl. code after DSPINT bit is set
then
> everything is OK - appl. code is sent correctly and it is running!
However, a
> little problem is still annoying because my small bootloader is still
sent during
> DSP internal reset and sometimes some words get corrupted.
Nevertheless, this is a
> solution for a moment.
> If somebody met such problem in the past or was anyhow concerned with
this please
> be so kind to let me know.
Some suggestions:
1) Minimize code sent prior to releasing the stall. All that's really
needed is a
2-instruction loop that does nothing . Once the chip is running you can
load any
other code and go from there.
2) During the stall period treat HPI more carefully. Slow down the rate
of access,
read back each word written, re-try until data is correct.
-Jeff
