BlackFin and SDRAM On EZ-Lite Problems

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

There is an issue with external memory on the 533 ezkit, but there is a
software patch for the ezkit on the ADI web page, did you download and
install it?

PD


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

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

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

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

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

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/

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

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