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