DSPRelated.com
Forums

Re: HPI booting problem

Started by Jeff Brower April 25, 2008
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
>>