Gigacart Issues

[Tursi]

I'm going to just drop out a quick request for ideas here. I've got the hardware built but I've been fighting to get it working to the point where I'm comfortable ordering the flash.

 

The cart is a basic extension of the classic bank-switched cartridge we've been building - expanded to 128MB. It uses two data bits in addition to all 12 usable address bits when it latched on write to accomplish this.

 

The latching and voltage conversion (5v <-> 3.3v) is performed via a 5v tolerant CPLD. Testing shows that it is reading and relaying all signals correctly in all cases I've tested.

 

I've tested that the latching works as expected - all banks select correctly and the address lines are presented to the flash chip as expected.

 

And most of the time (better than 99%), everything works correctly.

 

However, seemingly at random, entire erase sectors on the flash (128k worth) read back as 0xFF bytes. When I read back the flash chip in my EPROM programmer, however, I don't see these empty blocks. The bad sectors are different on every chip and move when I reprogram the chip (however, the programmer always verifies correctly, even if I insert the chip the next day and read it back).

 

Even though I say 'at random', the 'bad' sectors do not move until the chip is reprogrammed. If not for reading them back on the PC I would truly assume they had failed to program.

 

I've put the circuit under a logic analyzer and can confirm that the chip itself is returning the 0xFF bytes. What's less clear is whether it's driving the bus at all, or the lines are just being pulled up by the CPLD. However, I can't see any difference between a good read and a bad read in terms of signalling or timing, and the flash erase sector boundaries makes me suspicious.

 

Here's what I've tried - none of these changes affected the behaviour in the end:

 

- there's a lot of transition jitter on the TI address bus - even after the !ROM line goes low. I added a clock to debounce the signals presented to the flash chip, so that it only sees clean transitions that don't appear to violate any of the datasheet timing diagrams

- I swapped !CE and !OE - in both cases one was tied low and the other was driven by !ROM (The CPLD gates whether the data is presented to the TI, so writes aren't a problem). The datasheet suggested I had them the wrong way around in terms of which transitioned first.

- Added/removed decoupling caps

- The chip is a 16-bit flash with an 8-bit mode - I disabled 8-bit mode and ran it in 16-bit mode to test. Behaviour remained the same.

 

If it was flaky, then I might at least attribute it to a bad socket or the copious bodge wires, but it's perfectly stable in circuit -- just wrong.

 

If the location of the bad sectors was fixed or predictable from the PC side, I could just work around it in software. But since I don't know until after it's programmed and plugged into the TI, and reprogramming it can move the fault, I'm stuck there.

 

Flash is a S29GL01GP MirrorBit from Spansion, CPLD is a Lattice LC4064. I'm running the circuit on 3.3v regulated from the TI's 5 via LDO.

 

Any ideas? I suppose the other thing to try is to build the other PCB I have, but I can't see any pattern that suggests bad PCB or build.

Edited June 21, 2018 by Tursi

[+Ksarul]

Let me mull this over some. . .

[Stuart]

"I've put the circuit under a logic analyzer and can confirm that the chip itself is returning the 0xFF bytes. What's less clear is whether it's driving the bus at all, or the lines are just being pulled up by the CPLD."

 

Could you put a 'weak' pull-down resistor on one of the data lines to tell if it's driving the bus, or if the line is just floating high?

[Tursi]

I think I've solved this... I wasn't allowing for a proper reset pulse, but the slow powerup of the console causes an unstable reset. Manually testing with wires got me a fairly reliable readback of the chip (all pages confirmed, but my hacking damaged the daughterboard and so there's some uncertainty in the addressing within a page). Going to undo my hacks this weekend and update the CPLD to manage the flash reset, but it's feeling like I've got it.

[Asmusr]

Cool. At the risk of sounding like a cliche, somehow it always helps to describe your problems in writing. I'm looking forward to seeing Dragon's Lair in action...