KG7HF wrote:

> Actually, Bernhard is talking about something completely
> different.  He is talking about having an emulator pod connected
> to a development board and the emulator pod supplying just enough
> power through the TDI/TDO/TMS signals to keep the dsp in somewhat
> of a powered state.
> 

That's not the case. I __did__ remove all cables. At least, I 
thought I did. 
I'd agree with what you say, especially because I own another board 
which is fully powered through USB, thus knowing of this issue.
I always remove the USB cable at first, then the power cable, then 
insert the power cable and after that the USB cable.
It's such a boring process, that I'd certainly have noticed the 
difference. 
But I don't mind if you doubt this - so do I...

Bernhard
 

Actually, Bernhard is talking about something completely different.  He is
talking about having an emulator pod connected to a development board and
the emulator pod supplying just enough power through the TDI/TDO/TMS signals
to keep the dsp in somewhat of a powered state.

As for the support line not knowing about the patch, well, I found out about
it from them, so at least someone there knows about it.


"Kevin Harvey" <kevin.harvey@fluke.com> wrote in message
news:bkrohk$jth$1@potlatch.tc.fluke.com...
> Yes Bernhard, there is some strange behaviour with the ADI development
> boards.
>
> In my case the patch suggested by KG7HF solved the problem. There was
indeed
> a problem with the way that ADI had implemented the SDRAM. It is a great
> shame that ADI's support team did not know about this and I had to get the
> answer from the newsgroup.
>
> I have always had first class (if sometimes slow) support from them.
Perhaps
> the heavy advertising on BlackFin has caused them to get a new bunch of
> support people and they have not trained them yet.
>
> Kevin
>
> "Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in message
> news:3621509.SLu6kcEnAo@holzmayer.ifr.rt...
> >
> > Sorry for the delayed answer...
> > What you describe, is obvious. Yes, I know, that it's necessary to
> > unplug the device, not only power cable, but USB cable, too.
> > I'm rather sure that I did so. Not only for a couple of seconds.
> > Let's say for at least 30seconds (maybe even 10minutes).
> >
> > Nothing changed - looked as if SPORT or DMA were partially dead.
> >
> > After the weekend, when I was about to debug the problem, it had
> > vanished. This happened a few times.
> > But, as you said: this sounds like voodoo/magic.
> > However, I don't believe in such occult things nor do I practice
> > them. therefore I told myself, that something must have been gone
> > wrong.
> > But now, when I read Kevin's note, I remembered this.
> > Gave me hope that I was not this stupid...
> >
> > Bernhard
>
>

Yes Bernhard, there is some strange behaviour with the ADI development
boards.

In my case the patch suggested by KG7HF solved the problem. There was indeed
a problem with the way that ADI had implemented the SDRAM. It is a great
shame that ADI's support team did not know about this and I had to get the
answer from the newsgroup.

I have always had first class (if sometimes slow) support from them. Perhaps
the heavy advertising on BlackFin has caused them to get a new bunch of
support people and they have not trained them yet.

Kevin

"Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in message
news:3621509.SLu6kcEnAo@holzmayer.ifr.rt...
>
> Sorry for the delayed answer...
> What you describe, is obvious. Yes, I know, that it's necessary to
> unplug the device, not only power cable, but USB cable, too.
> I'm rather sure that I did so. Not only for a couple of seconds.
> Let's say for at least 30seconds (maybe even 10minutes).
>
> Nothing changed - looked as if SPORT or DMA were partially dead.
>
> After the weekend, when I was about to debug the problem, it had
> vanished. This happened a few times.
> But, as you said: this sounds like voodoo/magic.
> However, I don't believe in such occult things nor do I practice
> them. therefore I told myself, that something must have been gone
> wrong.
> But now, when I read Kevin's note, I remembered this.
> Gave me hope that I was not this stupid...
>
> Bernhard

Kenneth Porter wrote:

> Bernhard Holzmayer <holzmayer.bernhard@deadspam.com> wrote in
> news:1673898.NrdPf7C3F0@holzmayer.ifr.rt:
> 
>> On a Sharc EZ-Lite board, I've watched similar
>> effects: that sometimes the board interfaces fail, and that it
>> needs a night or a weekend to recover.
> 
> I recall similar voodoo debugging when first using the SHARC, and
> it took me quite awhile before I figured out how to get things
> unwedged with minimal effort.
> 
> The real problem is that the JTAG interface is easily hung, and
> the JTAG cable to the host will provide power to the chip and hold
> it in the hung state even when you reset the target.
> 
> To fix this, disconnect the JTAG cable, power-cycle the target,
> then plug the JTAG back in. You have to completely get power away
> from the SHARC for a few seconds to make sure the internal JTAG
> machine on the chip is fully reset.
> 

Sorry for the delayed answer...
What you describe, is obvious. Yes, I know, that it's necessary to 
unplug the device, not only power cable, but USB cable, too.
I'm rather sure that I did so. Not only for a couple of seconds. 
Let's say for at least 30seconds (maybe even 10minutes).

Nothing changed - looked as if SPORT or DMA were partially dead.

After the weekend, when I was about to debug the problem, it had 
vanished. This happened a few times.
But, as you said: this sounds like voodoo/magic. 
However, I don't believe in such occult things nor do I practice 
them. therefore I told myself, that something must have been gone 
wrong. 
But now, when I read Kevin's note, I remembered this.
Gave me hope that I was not this stupid...  

Bernhard

Bernhard Holzmayer <holzmayer.bernhard@deadspam.com> wrote in 
news:1673898.NrdPf7C3F0@holzmayer.ifr.rt:

> On a Sharc EZ-Lite board, I've watched similar 
> effects: that sometimes the board interfaces fail, and that it 
> needs a night or a weekend to recover.

I recall similar voodoo debugging when first using the SHARC, and it took 
me quite awhile before I figured out how to get things unwedged with 
minimal effort.

The real problem is that the JTAG interface is easily hung, and the JTAG 
cable to the host will provide power to the chip and hold it in the hung 
state even when you reset the target.

To fix this, disconnect the JTAG cable, power-cycle the target, then plug 
the JTAG back in. You have to completely get power away from the SHARC for 
a few seconds to make sure the internal JTAG machine on the chip is fully 
reset.

-- 
Kenneth Porter
http://www.sewingwitch.com/ken/

Fantastic! Just what I was looking for.

Thanks

"KG7HF" <KG7HF@amsat.org> wrote in message
news:rZqab.1101$iT4.656805@news1.news.adelphia.net...
> I don't know if this link will work.
>
>
http://www.analog.com/Analog_Root/sitePage/mainSectionContent/0,2132,level4%253D%25252D1%2526ContentID%253D10928%2526level1%253D205%2526level2%253D211%2526level3%253D%25252D1,00.html#tar15157
>
> But here it is.  You could also look on the tools anomaly page for
TAR15157
>
>

I don't know if this link will work.

http://www.analog.com/Analog_Root/sitePage/mainSectionContent/0,2132,level4%253D%25252D1%2526ContentID%253D10928%2526level1%253D205%2526level2%253D211%2526level3%253D%25252D1,00.html#tar15157

But here it is.  You could also look on the tools anomaly page for TAR15157


"Kevin Harvey" <kevin.harvey@fluke.com> wrote in message
news:bk9sl1$dq2$1@potlatch.tc.fluke.com...
>
> I've recently been trying to get the SDRAM working on my BF533 EZ-Kit
Lite,
> to no avail!  The development environment is supposed to setup the SDRAM
> registers by default, if this feature is enabled, which it is.  I've also
> tried setting them up manually.  The problem is if I try and modify the
> memory, say address 0x00000000 or 0x00000002, using the memory viewer it
> doesn't actually succeed in writing to the memory.  In fact it comes back
> with a memory verification error and the EZ-Lite board then hangs up and
is
> a pain to get going again.  If fact after power cycling the PC and EZ-Lite
> board, when the board is down loaded too the following messages appear.
>
> Loading: "C:\Program Files\Analog
> Devices\VisualDSP\Blackfin\EZ-Kits\ADSP-BF533\Examples\Filter Test
> Harness\AD_Code\Debug\Filter_Harness.dxe"...
>
> Could not halt after reset
> Data verification failed at address: 0xffa000bc
> Expected: 0x00, Found: 0x01
> Data verification failed at address: 0xff903000
> Expected: 0x00, Found: 0x01
> Data verification failed at address: 0xff902000
> Expected: 0x00, Found: 0x01
> Data verification failed at address: 0xffb00004
> Expected: 0x00, Found: 0x01
> Data verification failed at address: 0xffa00000
> Expected: 0x07, Found: 0x01
> Data verification failed at address: 0xffa00940
> Expected: 0x25, Found: 0x01
> Error writing breakpoint at address: 0xffa00940.
> Data verification failed at address: 0xffa004d6
> Expected: 0x25, Found: 0x00
> Error writing breakpoint at address: 0xffa004d6.
> Load complete.
> Data verification failed at address: 0xffa00330
> Expected: 0x25, Found: 0x01
> Error writing breakpoint at address: 0xffa00330.
>
>
> This situation seems to persist until the EZ-Lite board has been turned
off
> for several hours, maybe even overnight, hence making debugging the
problem
> rather difficult!!
>
>
> Has anyone used SDRAM successfully?  Or had similar problems with a
> non-volitile type lock-up of the EZ-Lite board?
>
>
> -- 
> Kevin Harvey
> Senior Software Engineer
> Fluke Precision Measurement, Norwich
>
>

Hi Bernhard,
Yes we have also used the SHARC Ez-Kit, and as you say that had 'issues'
with SDRAM :))

We are also chasing this up via support (who I must say in the past have
been exceptionally helpful). But so far they have not be that useful.

Kevin

Hi KG7HF,
I did not know there was a patch, I have not been able to locate it. Any
chance you can give me a pointer to it?

Ta
Kevin

Kevin Harvey wrote:

> 
> ...
> 
> This situation seems to persist until the EZ-Lite board has been
> turned off for several hours, maybe even overnight, hence making
> debugging the problem rather difficult!!
> 

Hi Kevin, 
that's interesting. On a Sharc EZ-Lite board, I've watched similar 
effects: that sometimes the board interfaces fail, and that it 
needs a night or a weekend to recover.
I thought, I'm stupid  - but now I guess that there might be a sort 
of memory effect.

Did you ask the ADI people for support? 
There are a lot of issues concerning SDRAM (at least on Sharc), 
which I had to learn at first. But this overnight problem still 
happens from time to time although in general SDRAM accesses work 
perfectly.

Bernhard

-- 
before sending to the above email-address:
replace deadspam.com by foerstergroup.de