Hi Jeff,
Thank you for the help. Finally, the problem with HPI is solved. Well,
since my last mail regarding the problem dates around 2 months back does
not mean all this time was spent for finding solution:-). Just on the
contrary, the problem solving took less than the day. Since they were my
colleagues who made hardware job, set timings, etc. I decided it would
be reasonable to ask them to make additional testing. They did it with
digital analyzer and found the problem very quickly. The change of the
value defining CPU cycles after transfer and number of wait states
solved the problem. So, you were quite right in one of your mails that
CPU (Atmel, in my case) code might be a source of the problem.
Also, my thanks to all who expressed comments or advices on this
problem.
With best regards,
Taras.
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Friday, February 22, 2008 6:11 PM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
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,
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.
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
