hi all.
I meet a strange problem about the C6713 HPI.
The dsp and the host can work well at most time, but sometimes it goes
wrong.
After the dsp sets the HINT bit of HPIC, the host can get the
intterrupt, but when the host want to clear the HINT bit, the HPI's HRDY
will always be high after the HCS's falling edge! Since then ,the host
and
the dsp can't work well.
I have checked the timing of the pins. They are all right except that
HRDY will always be high after the HCS's falling edge.
I am puzzled about it and can't find the reason. I hope somebody
can
give me a hint.
Thanks!
--
Wang,Shucheng
State Key Lab of Fluid Power Transmission and Control
ZheJiang University,HangZhou
PR.China
A problem about C6713 HPI
Started by ●January 18, 2007
Reply by ●January 18, 20072007-01-18
Shucheng Wang-
> I meet a strange problem about the C6713 HPI.
> The dsp and the host can work well at most time, but sometimes it goes
> wrong.
> After the dsp sets the HINT bit of HPIC, the host can get the
> intterrupt, but when the host want to clear the HINT bit, the HPI's HRDY
> will always be high after the HCS's falling edge! Since then ,the host and
> the dsp can't work well.
> I have checked the timing of the pins. They are all right except that
> HRDY will always be high after the HCS's falling edge.
> I am puzzled about it and can't find the reason. I hope somebody can
> give me a hint.
HRDY gets stuck when the internal 67xx HPI state-machine gets confused. This can
happen with HHWIL failing to alternate, 'wrong' combinations of auto-increment and
non-auto-increment accesses, etc. Also there were quite a lot of errata with 67xx
HPI having to do with the last 1 or 2 words in an auto-increment block access and
specific things you had to do to "flush" the HPI FIFOs -- I don't know if those still
apply, but strongly urge you to check the errata for your 6713 silicon revision.
Basically, I doubt the problem has anything to do with HINT, HPIC, /HCS - HRDY timing
relationship, PC driver, etc.
-Jeff
> I meet a strange problem about the C6713 HPI.
> The dsp and the host can work well at most time, but sometimes it goes
> wrong.
> After the dsp sets the HINT bit of HPIC, the host can get the
> intterrupt, but when the host want to clear the HINT bit, the HPI's HRDY
> will always be high after the HCS's falling edge! Since then ,the host and
> the dsp can't work well.
> I have checked the timing of the pins. They are all right except that
> HRDY will always be high after the HCS's falling edge.
> I am puzzled about it and can't find the reason. I hope somebody can
> give me a hint.
HRDY gets stuck when the internal 67xx HPI state-machine gets confused. This can
happen with HHWIL failing to alternate, 'wrong' combinations of auto-increment and
non-auto-increment accesses, etc. Also there were quite a lot of errata with 67xx
HPI having to do with the last 1 or 2 words in an auto-increment block access and
specific things you had to do to "flush" the HPI FIFOs -- I don't know if those still
apply, but strongly urge you to check the errata for your 6713 silicon revision.
Basically, I doubt the problem has anything to do with HINT, HPIC, /HCS - HRDY timing
relationship, PC driver, etc.
-Jeff
Reply by ●January 19, 20072007-01-19
Jeff:
It is true that we made a mistake to visit a unexpected address in
0x60000000~0x7FFFFFFF, and it caused the HRDY to be always high, which is
listed in the errta.
Thank you very much!
On 1/19/07, Jeff Brower wrote:
>
> Shucheng Wang-
>
> > I meet a strange problem about the C6713 HPI.
> > The dsp and the host can work well at most time, but sometimes it
> goes
> > wrong.
> > After the dsp sets the HINT bit of HPIC, the host can get the
> > intterrupt, but when the host want to clear the HINT bit, the HPI's HRDY
> > will always be high after the HCS's falling edge! Since then ,the host
> and
> > the dsp can't work well.
> > I have checked the timing of the pins. They are all right except
> that
> > HRDY will always be high after the HCS's falling edge.
> > I am puzzled about it and can't find the reason. I hope somebody
> can
> > give me a hint.
>
> HRDY gets stuck when the internal 67xx HPI state-machine gets
> confused. This can
> happen with HHWIL failing to alternate, 'wrong' combinations of
> auto-increment and
> non-auto-increment accesses, etc. Also there were quite a lot of errata
> with 67xx
> HPI having to do with the last 1 or 2 words in an auto-increment block
> access and
> specific things you had to do to "flush" the HPI FIFOs -- I don't know if
> those still
> apply, but strongly urge you to check the errata for your 6713 silicon
> revision.
>
> Basically, I doubt the problem has anything to do with HINT, HPIC, /HCS -
> HRDY timing
> relationship, PC driver, etc.
>
> -Jeff
>
--
Wang,Shucheng
State Key Lab of Fluid Power Transmission and Control
ZheJiang University,HangZhou
PR.China
It is true that we made a mistake to visit a unexpected address in
0x60000000~0x7FFFFFFF, and it caused the HRDY to be always high, which is
listed in the errta.
Thank you very much!
On 1/19/07, Jeff Brower wrote:
>
> Shucheng Wang-
>
> > I meet a strange problem about the C6713 HPI.
> > The dsp and the host can work well at most time, but sometimes it
> goes
> > wrong.
> > After the dsp sets the HINT bit of HPIC, the host can get the
> > intterrupt, but when the host want to clear the HINT bit, the HPI's HRDY
> > will always be high after the HCS's falling edge! Since then ,the host
> and
> > the dsp can't work well.
> > I have checked the timing of the pins. They are all right except
> that
> > HRDY will always be high after the HCS's falling edge.
> > I am puzzled about it and can't find the reason. I hope somebody
> can
> > give me a hint.
>
> HRDY gets stuck when the internal 67xx HPI state-machine gets
> confused. This can
> happen with HHWIL failing to alternate, 'wrong' combinations of
> auto-increment and
> non-auto-increment accesses, etc. Also there were quite a lot of errata
> with 67xx
> HPI having to do with the last 1 or 2 words in an auto-increment block
> access and
> specific things you had to do to "flush" the HPI FIFOs -- I don't know if
> those still
> apply, but strongly urge you to check the errata for your 6713 silicon
> revision.
>
> Basically, I doubt the problem has anything to do with HINT, HPIC, /HCS -
> HRDY timing
> relationship, PC driver, etc.
>
> -Jeff
>
--
Wang,Shucheng
State Key Lab of Fluid Power Transmission and Control
ZheJiang University,HangZhou
PR.China
Reply by ●January 19, 20072007-01-19
Sucheng-
> It is true that we made a mistake to visit a unexpected address in
> 0x60000000~0x7FFFFFFF, and it caused the HRDY to be always high, which is
> listed in the errta.
> Thank you very much!
Sure. Glad to hear that you have it working!
-Jeff
> On 1/19/07, Jeff Brower wrote:
> >
> > Shucheng Wang-
> >
> > > I meet a strange problem about the C6713 HPI.
> > > The dsp and the host can work well at most time, but sometimes it
> > goes
> > > wrong.
> > > After the dsp sets the HINT bit of HPIC, the host can get the
> > > intterrupt, but when the host want to clear the HINT bit, the HPI's HRDY
> > > will always be high after the HCS's falling edge! Since then ,the host
> > and
> > > the dsp can't work well.
> > > I have checked the timing of the pins. They are all right except
> > that
> > > HRDY will always be high after the HCS's falling edge.
> > > I am puzzled about it and can't find the reason. I hope somebody
> > can
> > > give me a hint.
> >
> > HRDY gets stuck when the internal 67xx HPI state-machine gets
> > confused. This can
> > happen with HHWIL failing to alternate, 'wrong' combinations of
> > auto-increment and
> > non-auto-increment accesses, etc. Also there were quite a lot of errata
> > with 67xx
> > HPI having to do with the last 1 or 2 words in an auto-increment block
> > access and
> > specific things you had to do to "flush" the HPI FIFOs -- I don't know if
> > those still
> > apply, but strongly urge you to check the errata for your 6713 silicon
> > revision.
> >
> > Basically, I doubt the problem has anything to do with HINT, HPIC, /HCS -
> > HRDY timing
> > relationship, PC driver, etc.
> >
> > -Jeff
> It is true that we made a mistake to visit a unexpected address in
> 0x60000000~0x7FFFFFFF, and it caused the HRDY to be always high, which is
> listed in the errta.
> Thank you very much!
Sure. Glad to hear that you have it working!
-Jeff
> On 1/19/07, Jeff Brower wrote:
> >
> > Shucheng Wang-
> >
> > > I meet a strange problem about the C6713 HPI.
> > > The dsp and the host can work well at most time, but sometimes it
> > goes
> > > wrong.
> > > After the dsp sets the HINT bit of HPIC, the host can get the
> > > intterrupt, but when the host want to clear the HINT bit, the HPI's HRDY
> > > will always be high after the HCS's falling edge! Since then ,the host
> > and
> > > the dsp can't work well.
> > > I have checked the timing of the pins. They are all right except
> > that
> > > HRDY will always be high after the HCS's falling edge.
> > > I am puzzled about it and can't find the reason. I hope somebody
> > can
> > > give me a hint.
> >
> > HRDY gets stuck when the internal 67xx HPI state-machine gets
> > confused. This can
> > happen with HHWIL failing to alternate, 'wrong' combinations of
> > auto-increment and
> > non-auto-increment accesses, etc. Also there were quite a lot of errata
> > with 67xx
> > HPI having to do with the last 1 or 2 words in an auto-increment block
> > access and
> > specific things you had to do to "flush" the HPI FIFOs -- I don't know if
> > those still
> > apply, but strongly urge you to check the errata for your 6713 silicon
> > revision.
> >
> > Basically, I doubt the problem has anything to do with HINT, HPIC, /HCS -
> > HRDY timing
> > relationship, PC driver, etc.
> >
> > -Jeff
