Taras-
> Maybe my sentence about colleagues was unclear and thus misunderstood. I just
> meant my colleagues here which are hardware engineers and, hopefully, did all
> necessary testing of signal timing. Nevertheless, Ill ask them to carry out
> additional, more in-depth testing, especially focusing on comparison HPI behavior
> in mentioned DSP states. This could be a clue.
>
> I have a 2-channel digital scope, but it is not much use of it, particularly in
> this case. Because there are too many HPI signals to check, often simultaneously.
> Smarter device is needed.
>
Well if it were me I wouldn't wait for the 'colleagues' since they've stuck you with
the problem and they're not on the group asking questions (maybe they should be). A
2-chan scope is fine. First, make sure /HCS is always low (i.e. tied low). No need
to move /HCS around in your first stage of getting things to work. Second, use /HDS
on one trace to trigger and look at some other signals. First make sure HR/W is
stable prior to onset of /HDS -- if not that could cause the error your seeing (the
device thinks it's a write but you think its a read, so HPI increments but data is
messed up). Third make sure HRDY is always indicating the device is ready (should
be, since you're not running any code or using internal DMA channels). Then make
sure /HDS itself meets data sheet specs for setup time, hold-time, duration.

Note, when I say /HDS I mean the combined internal strobe -- typically HDS1 tied high
and /HDS2 used as the external strobe.

-Jeff
> ------------
> From: Jeff Brower [mailto:j...@signalogic.com]
>
> Sent: Thursday, February 21, 2008 7:33 PM
> To: Kurnytskyi Taras
> Cc: c...
> Subject: Re: [c6x] HPI booting problem
>
> Taras-
>
> 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.
> At this point I would focus on verifying HPI signals and timing for HPI read.
> There is no way you should get "half" success. If you are saying you don't have a
> digital scope, then get one -- you can't expect help from the group unless you're
> able to make timing measurements and verify that you're not "guessing" to meet the
> data sheet.
>
> If you have some known DSP memory data, then testing read first is a good idea as
> it simplifies the problem. I don't know whether it's valid to read EMIF registers
> -- those are memory-mapped and not all memory-mapped registers are available to HPI
> in the C671x architecture. But if you get correct answers in any case then it's
> probably Ok.
>
>> By the way, how can I slow down the rate of access?
>> Put a long delay in between each HPI read.
>
> -Jeff
>
>> -----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
>

Jeff,

Maybe my sentence about 'colleagues' was unclear and thus misunderstood.
I just meant my colleagues here which are hardware engineers and,
hopefully, did all necessary testing of signal timing. Nevertheless,
I'll ask them to carry out additional, more in-depth testing, especially
focusing on comparison HPI behavior in mentioned DSP states. This could
be a clue.

I have a 2-channel digital scope, but it is not much use of it,
particularly in this case. Because there are too many HPI signals to
check, often simultaneously. Smarter device is needed.

Taras.

_____

From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Thursday, February 21, 2008 7:33 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem

Taras-

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.
At this point I would focus on verifying HPI signals and timing for HPI
read. There is no way you should get "half" success. If you are saying
you don't have a digital scope, then get one -- you can't expect help
from the group unless you're able to make timing measurements and verify
that you're not "guessing" to meet the data sheet.

If you have some known DSP memory data, then testing read first is a
good idea as it simplifies the problem. I don't know whether it's
valid to read EMIF registers -- those are memory-mapped and not all
memory-mapped registers are available to HPI in the C671x architecture.
But if you get correct answers in any case then it's probably Ok.

By the way, how can I slow down the rate of access?
Put a long delay in between each HPI read.

-Jeff

-----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

Taras-
> 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.

At this point I would focus on verifying HPI signals and timing for HPI read. There
is no way you should get "half" success. If you are saying you don't have a digital
scope, then get one -- you can't expect help from the group unless you're able to
make timing measurements and verify that you're not "guessing" to meet the data
sheet.

If you have some known DSP memory data, then testing read first is a good idea as it
simplifies the problem. I don't know whether it's valid to read EMIF registers --
those are memory-mapped and not all memory-mapped registers are available to HPI in
the C671x architecture. But if you get correct answers in any case then it's
probably Ok.
> By the way, how can I slow down the rate of access?

Put a long delay in between each HPI read.

-Jeff
> -----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

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

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
>

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

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.

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