Hi,
They simply increased number of wait states from 6 to 8.
With best regards,
Taras
_____
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Saturday, April 26, 2008 12:57 AM
To: Kurnytskyi Taras
Cc: c...
Subject: Re: [c6x] HPI booting problem
Kurnytskyi-
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.
Ok great to hear your bug is vanquished! That's always a good feeling
in engineering. Did your hardware colleagues just add delay (wait
states), or did they treat the HRDY signal differently?
Thank you for letting the group know what turned out to be the problem.
-Jeff
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