Hi Chris,
we had a problem with SDRAM access in that the DSP's minimum SDRAM data
input hold time tHDSDK was larger than expected, see anomaly #31 of the
ADSP21161 anomaly sheet.
This resulted in corrupt data being read from the SDRAM, but only when the
reading was in consecutive cycles.
The solution, approved by ADI, was to add a small capacitor on the SDRAM
clock line to ground, this skewed the clock and moved the time window for
valid
data.
Our specific solution was to place the cap. (22pF, surface mount NP0) near to
the
SDRAM. As the anomaly sheet explains, for each board layout, the value and
location may need to be different.
Hope this helps,
Alex Young
DSP software Engineer
Consultant for Philips Digital Systems Laboratories
To: "'Mike Rosing'"
<>
cc: <
(bcc: Alex
Young/LEU/PDSL/PHILIPS)
Subject: RE: [adsp] Reload
issue with SummitICE on 21161
"Chris Lockwood"
< Classification:
>
20/06/03 08:58
Hi Mike,
Thanks for your help so far, but we still haven't solved the problem.
Its been a week of (expensive) hell! I contacted AD the other day and
provided them with info. Still haven't heard back from them (apart from
the automated response).
Since last post-
1)Supplies are OK (within the 100mV noise floor of our HP cro) at all
times.
2)I added another 10 decoupling caps under the DSP just to be sure! No
difference.
3)The problem is not the emulator. It happens without the emulator ever
being attached after a power-up, with the JTAG lines jumpered to ground,
booting from FLASH. The problem actually happens consistently with some
applications during the bootload operation's copying phase. The problem
is related to the data being moved around.
4)The problem is marginal at times. It ran for over 12 hours last night,
with a full TCP stack pinging away. It runs entirely from SDRAM-
program, stack, and heap are all in SDRAM for this module. If it runs
from SDRAM for 12 or more hours, I doubt it's a bus timing problem.
Besides- this should not cause DSP silicon to lock up. The code was
loaded through the emulator, set running, and then JTAG pins jumpered to
ground.
5) The bootloader DMAs 6 bytes at a time from FLASH using the BMS line,
packs this into 48 bits, then writes to SDRAM (48 bits wide). The
strobes die at different places in the operation, but ALWAYS after a
successful DMA transfer (ie 6-byte boundaries are OK). All subsequent
DMA transfers copy the same value- being the last byte successfully read
from FLASH, indicating the point where the strobes died.
6) The last data value successfully written to SDRAM before it dies
always has mostly 0xFs in it (ie 0xXXXXFFFFFFXX). The preceding value
written to SDRAM is mostly 0x0s (ie 0xXXXX000000XX). It happens at
different parts of the image with this pattern- this pattern doesn't
always cause it to fail, but every failure happens with this pattern.
Coincidence?
7) During bootload, the FPGA is in unconfigured state- it does not pull
any of the bus lines. The only other device attached to the strobes is
the FLASH. The data and address lines are hooked to the SDRAM, FLASH,
FPGA(inactive), and the upper 16 bits to a LAN device (input only on
these pins).
Any other ideas?????
Next is to try a different revision of the silicon. We are using 1.1-
both prototypes use devices from the same tray. We have a few old protos
with 1.0, and we never saw this problem running very similar code, and
similar hardware design (different layout). Not too keen on trying to
recycle a BGA device- we have no new 1.0s.
Chris
-----Original Message-----
From: Mike Rosing [mailto:]
Sent: Friday, June 13, 2003 11:28 PM
To: Chris Lockwood
Cc:
Subject: RE: [adsp] Reload issue with SummitICE on 21161
On Fri, 13 Jun 2003, Chris Lockwood wrote:
> Thanks for the info. The lack of read or write
strobe suggests that
its
> going into a 'slave' mode, which could
happen if either DMARx lines
> assert. These were floating (internal pull-ups too weak?) so I tried
> tying them directly to VCC- no difference.
>
> I went through every IO pin and made sure they were directly connected
> to VCC if they were input-only, and pulled the rest up with 10K where
an
> internal pullup resistor was not specified.
It was a good try anyway!
> It appears to end up in several different states
each time the program
> is loaded through JTAG. One of these treats the entire external memory
> space as a single register (?!!). Chip selects appear to be
functioning
> correctly, but the data does not get through. Ie I
write a value
> anywhere, and any address in external memory reads that value back.
> SDRAM and internal memory still functions normally. Its as if the
> external memory controller is disconnected from the internal bus.
Either that or the internal emulator functions are messed up. The
px register is used by the emulator to transfer data to the jtag,
as well as external memory. If the address decoder is locked up,
the px register is all you can see.
> Another weird condition just stops all accesses to
external memory- no
> read or write strobes. The strange thing is it appears to read the
last
> value that was read from external memory before
the JTAG load
operation.
>
> The only way it can recover is if I physically repower the DSP. The
> hardware reset does not fix it, even if I pull off the emulator as
well.
The internal emulator is screwed. If you can replicate it, it's worth
talking to the ADI support guys about it. It may be the current supply
or it may be a bug in the emulator.
> Could it be that the JTAG data is getting
corrupted, and the dodgy
data
> is putting the DSP into some weird, unrecoverable
state? The summitICE
> emulators we use have always been notoriously unreliable when it comes
> to getting a connection. This does not inspire much confidence.
I don't think the data is corrupt, I think the internal logic of the
emulator is messed up some how.
> This problem seems closely related to the size of
the executable.
Small
> projects seem to have less problems. Large ones
very rarely succeed.
That was my experience with the dma lock up too. That could be a
current
limit problem. What's the power supply look like during the loading?
Maybe look at each Vcc or Vdd and see if they are all rock solid.
> My thoughts are that it might be a JTAG problem.
Hard to confirm
though!
> The only difference between this and other
platforms using 21161 is
the
> distance of the connector to the DSP. Ours is a
whole 2" (5cm) away!
> Anyone know of any issues with this?
Short cables are good, short lines are good too. 5cm shouldn't be much
of a problem, especially if you have ground planes.
> It still hasn't crashed when booting from
FLASH.
That's because the emulator logic isn't invoked. If your power
supplys
look good on every pin, then start talking with ADI support. They may
have a work around for a known bug already.
Patience, persistence, truth,
Dr. mike
_____________________________________
Note: If you do a simple "reply" with your email client, only the
author
of this message will receive your answer. You need to do a "reply
all"
if you want your answer to be distributed to the entire group.
_____________________________________
About this discussion group:
To Join: Send an email to
To Post: Send an email to
To Leave: Send an email to
Archives: http://groups.yahoo.com/group/adsp
Other Groups: http://www.dsprelated.com/groups.php3
">http://docs.yahoo.com/info/terms/
_____________________________________
Note: If you do a simple "reply" with your email client, only the
author of this
message will receive your answer. You need to do a "reply all" if you
want your
answer to be distributed to the entire group.
_____________________________________
About this discussion group:
To Join: Send an email to
To Post: Send an email to
To Leave: Send an email to
Archives: http://groups.yahoo.com/group/adsp
Other Groups: http://www.dsprelated.com/groups.php3
">http://docs.yahoo.com/info/terms/
|