External SRAM access - reading wrong values

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been running into a data storage problem while trying to sample audio. I am using an ICE200 to emulate an 8515, and plan to implement the actual circuit with a MEGA161.
The problem is testing the external Static RAM. I load the SRAM locations with 0xBB and read back mostly 0xBB, but there are occasional byte clusters of 0xFF and 0x00. Each time the RAM test program is run the wrong values are read from different locations.
This is with a wire-wrapped prototype board. The static RAM is connected to the AVR bus through a 74HC573 bus demultiplexer. The crystal is 3.6864MHz and the 62256 32Kx8 Static RAM is rated at 120nS.
The 8515 has the external bus enable bit activated in the MCUCR. I'm viewing the results of the external Static RAM with AVR Studio 4. The RAM is connected to the AVR with the AVR RD\ going to the RAM's \OE and the AVR \WR going to the RAM's \WE. The RAM's \CE is tied low to ground. I am writing to the 32K range of 0x8000 to 0xFFFF. Stable regulated +5v on VCC and decoupling caps 0.047uF on each chip.
I tested several 32Kx8 Static RAMs on several other older wire-wrapped MCU demo boards (for both the 8051 and the 6809) and the SRAMs test OK. These boards test RAM by writing 0x55 to each location, verify, and repeat with 0xAA.

Does anyone have any ideas about what could be causing this? Also, is there a proper name for this phenomenon?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well there is an erata posted on the 8515 about not using a NOP after an LDS/STS to external memory. Are you doing that by some chance?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We've just been discussing this in another thread (AT89S8515 on a breadboard). There's a problem with the 8515 external memory interface, that there's zero data hold time after the rising edge of /WR. The device immediately changes the data bus to the next low address, so if your RAM takes a few nanoseconds to latch the data, it may have changed. Check out the electrical timing specs of the RAM - look up the minimum data hold time after /WR rising edge. It better be zero, but that doesn't guarantee you'll be trouble free because it takes a few nanoseconds for the signals to arrive from the CPU.

There's a complication because you're using an ICE - you can't be certain it's emulating the 8515 to the data-sheet nanosecond. But you should be able to see if there's a race condition if you scope /WR and one of the data lines at the RAM pins and trigger off /WR rising edge.

If this is what's causing the problem, it won't be an issue with the Mega161, which holds the data bus the correct amount of time.

Quote:
Also, is there a proper name for this phenomenon?

If it turns out to be the RAM timing, the proper name is "Human Error through Failure to Read the Specs" :twisted: