Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

Ads

#51 2020-01-03 00:54:27

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Tauwasser wrote:

Well, you haven't shown the bottom side yet

Oops, yeah I guess that would help wouldn't it? Also, not sure if this is any help, but here is a dropbox link with the diptrace and gerber files.
There's a lot going on in that layer, and I'm not sure how much I can improve on it. So many signals, so little board space....

Tauwasser wrote:

You really want to have the ground plane surround the RTC crystal pads and possibly connect the ground island north of the RTC's GND pin to the pin as well.

I'm not sure why the copper pour doesn't connect to that pin automatically. I ran a trace to connect the island. I'm not sure how to surround the crystal and its pads without vBatt and /CS getting in the way. Is the ground plane even necessary as long as the crystal is properly isolated?

EDIT:
had some time to look at that link. Since I opted for a SMD crystal, I guess I should be paying attention to the second image.
https://i.imgur.com/Jm9Jwvlm.png

So I should be trying to get a layout like this? I hadn't considered running the guard ring between 2 of the RTC pins. Thanks for that link, this is a gold mine of information. My last flashcart was off by about 15 minutes after a year of runtime, so it would be nice to get a handle on this topic.

Front:
https://i.imgur.com/PMs94X3l.png

Back:
https://i.imgur.com/ErN8fBGl.png

Last edited by WeaselBomb (2020-01-03 11:37:30)

Offline

 

#52 2020-01-03 16:05:15

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

WeaselBomb wrote:

I'm not sure why the copper pour doesn't connect to that pin automatically.

There is a minimum width setting that likely prevents it.

WeaselBomb wrote:

Is the ground plane even necessary as long as the crystal is properly isolated?

It helps, because it provides a defined reference voltage around the crystal and is supposed to shield it from noise. There are also minimal leakage currents along the surface of a PCB, which the ground will "catch".
More optimal would be if this ground were separate from the overall ground and only connected in one point to the ground of the MachXO, which in turn would only be connected in one point to the cartridge ground and so on.

WeaselBomb wrote:

So I should be trying to get a layout like this? I hadn't considered running the guard ring between 2 of the RTC pins. Thanks for that link, this is a gold mine of information. My last flashcart was off by about 15 minutes after a year of runtime, so it would be nice to get a handle on this topic.

A guard ring will likely not fit between the pins. I think their pitch is 0.5mm and your minimal trace width is currently 0.2mm and could go down to ~0.15mm when using cheap PCB processes, so your options are limited there.
Instead of using a guard ring, I would connect the grounds in one point to keep high-frequency noise close to the respective IC. It's never going to be optimal, nevertheless that step alone will improve the design. It's kind of a compromise between star routing and multi-point connections.

It's somewhat unfortunate how cut up the lower part of the back of the PCB is, because all the return currents will have to go around the cut or jump through multiple vias.
You should also replicate the little VBAT rectangle on the top directly like that on the bottom or the second via becomes kind of useless (as all the current has to go across the annular ring of the first via).

Last edited by Tauwasser (2020-01-03 16:14:07)

Offline

 

#53 2020-01-03 19:12:33

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Tauwasser wrote:

It's somewhat unfortunate how cut up the lower part of the back of the PCB is, because all the return currents will have to go around the cut or jump through multiple vias.

I was actually just thinking about this yesterday, what do you think of this and this?
Alternatively, I could maybe route the 3v3 rail below the mounting hole as well (between the bottom of the mounting hole and the 5v rail), which would allow ground to flow above the mounting hole?
I could also probably move C1, lower the 3v3 rail on the left side, which would let ground flow to the left side more easily?

Tauwasser wrote:

Instead of using a guard ring, I would connect the grounds in one point to keep high-frequency noise close to the respective IC. It's never going to be optimal, nevertheless that step alone will improve the design. It's kind of a compromise between star routing and multi-point connections.

Sounds good to me. I'll try to see what I can do about adding a local ground plane. I'll have to play around with it and see the best way to route the serial traces and vBatt.

Last edited by WeaselBomb (2020-01-03 19:21:05)

Offline

 

#54 2020-01-03 22:15:28

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

Hi WeaselBomb,

I took your Dip file and made some crude changes to illustrate what I meant by the 3V3 and 5V0 cutting through the board. Basically, I moved both of them to the top layer, since the ground plane is broken there already and there isn't really any need to have these traces on the bottom to begin with. You should add more vias to the ground plane in some places, but I use the freeware version of DipTrace and it complains that there are already 300 pins smile

You can probably do better, especially since I had trouble adjusting the trace widths for the individual segments. I tried to different styles of arcs around the center hole, but placing them at the exact radius by hand would have taken more time smile Obviously, if you can make them go around nice and easy with the same radius from the hole that'd look better and avoid the angles.

https://pics.tauwasser.eu/images/2020/01/04/Front.md.pnghttps://pics.tauwasser.eu/images/2020/01/04/Back.md.png

Last edited by Tauwasser (2020-01-03 22:17:46)

Offline

 

#55 2020-01-04 03:17:14

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

That looks great! I think I ran them on the bottom to ensure they went through the capacitors before reaching the pins. I don't remember why I was trying to do that, probably read it on some forum and went with it. I like the layout you made a lot better.

I've never actually used the arc feature, I'll have to play around with it and see what I can do.

EDIT: What do you think? I can probably squeeze the caps a little closer together if need be.
https://i.imgur.com/brqyRgjl.png

Last edited by WeaselBomb (2020-01-04 03:44:01)

Offline

 

#56 2020-01-04 13:00:48

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

It's looking good big_smile You might want to move the power traces closer together and add more vias to the middle gnd polygon as that's your main ground for decoupling the 5V0 side of the level shifters.

I prototyped the edit for X1 I suggested using keepout lines. I'm not 100% happy as tweaking the polygons using the keepout lines was somewhat tedious.

https://pics.tauwasser.eu/images/2020/01/04/front.md.pnghttps://pics.tauwasser.eu/images/2020/01/04/back.md.png

The idea is that the polygons on the front and back surround the X1 pads and the point of connection is on the GND pin on the top. The polygon on the bottom could probably go a bit lower.
Since the GND island south of the GND pin is the main GND connection, I added two move vias there just to be safe.

Oh yeah, I set the main GND poly to 0.3mm line width and line spacing down from 0.635mm. That really helped with getting the poly to connect on the sides.

Last edited by Tauwasser (2020-01-04 13:02:58)

Offline

 

#57 2020-01-05 15:26:40

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

And today I learned about keepout lines! Definitely makes pouring isolated ground planes easier.
I adjusted the power rails and added some vias, so I think it's well-grounded now?

If we need more room on the left side, I'm thinking the FPGA could maybe be shifted slightly to the right to free up some space?
Is the copper pour for vBatt necessary? The datasheet says it will only draw 1 micro-amp at most from the battery, which sounds like it only needs a small trace. I added the copper pour without much reasoning aside from the fact that it's a power rail.

Adjusted Power Rails:
https://i.imgur.com/mQi3biDl.png

Proposed RTC Layout:
https://i.imgur.com/TzD7zn2m.png

https://i.imgur.com/Kt35Et9m.png

Last edited by WeaselBomb (2020-01-05 15:29:19)

Offline

 

#58 2020-01-05 20:05:40

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

WeaselBomb wrote:

I adjusted the power rails and added some vias, so I think it's well-grounded now?

Yeah, it's better now. Did you make the new vias square or is that just an artifact?

WeaselBomb wrote:

If we need more room on the left side, I'm thinking the FPGA could maybe be shifted slightly to the right to free up some space?

Yeah, I thought about that as well, but I did not want to unnecessarily create additional work. If push came to shove, that would have been an option.

WeaselBomb wrote:

Is the copper pour for vBatt necessary? The datasheet says it will only draw 1 micro-amp at most from the battery, which sounds like it only needs a small trace. I added the copper pour without much reasoning aside from the fact that it's a power rail.

No, it's more of an more area = less resistance thing, I suppose. But for your purposes it really comes down to a style choice.

Offline

 

#59 2020-01-05 22:44:07

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Tauwasser wrote:

Yeah, it's better now. Did you make the new vias square or is that just an artifact?

Just an artifact, I was zoomed out too far.

Tauwasser wrote:

No, it's more of an more area = less resistance thing, I suppose. But for your purposes it really comes down to a style choice.

In that case I guess I'll go ahead and swap them out for traces.

I'm thinking about using PcbCart.com when it comes time for a proper production run, so I looked at their website and found these requirements for boards using 2 oz. copper:

-wire to wire: 8 mil
-wire to copper: 8 mil
-wire to via clearance: 10 mil
-wire to pad clearance: 10 mil
-wire to edge of pcb: 10 mil
-via to edge of pcb: 12 mil
-pad to edge of pcb: 12 mil
-min drill diameter: 6 mil
-min annular ring: 3 mil

From what I've read, I imagine this board would ideally use only 1 oz., but I thought it would be nice to be above the minimum requirements. I went ahead and adjusted the board to meet these specs. Vias are still .4, .7 mm.

At this point, I'm thinking it's about ready for a prototype run unless you have any more nuggets of wisdom.

https://i.imgur.com/1cP6Cchl.png

https://i.imgur.com/PGsOSvxl.png

Last edited by WeaselBomb (2020-01-05 22:51:27)

Offline

 

#60 2020-02-12 21:17:48

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Ok, boards are in and soldered! A little plastic tab on the cartridge shell is colliding with the right-most capacitor, so I've adjusted the PCB file to compensate.

The next disaster is that my combination of hardware/software doesn't seem to support the flash chip I chose (S29GL064S70TFI040). It's one of those 16-bit parts that can be run in 8-bit mode

For software, I am using your gbcflsh program. For hardware, I am using the J. Rodrigo cart flasher. I also have BennVenn's flasher, but so far, none of these have been able to read/write the flash chip correctly.

I finally noticed that there is a fork of that GBCartFlasher repo that claims to support mx29lv parts, which appears to have identical pinouts to my own chip. I guess if I can compile that and program the Atmega 8515 on my flasher, then it might work? The README says that it only works with 12 MHz crystals, but that shouldn't be too hard to change back to 6 MHz, right? Worst case, maybe I could desolder the old crystal and drop a 12 Mhz on there.

Unless there is another branch I should be looking at? Right now I'm leaning towards editing the fork that supports mx29lv, but I'm very open to suggestions.

Unfortunately, J. Rodrigo didn't include pins to program the Atmega. Guess I will have to solder some in.
Also, I have 3 programmers (Microchip, Lattice, and Xilinx) that I have used to program CPLDs/FPGAs, but I don't think any of them are compatible with the Atmega. Guess it's time to cave and get an AVRISP.

Last edited by WeaselBomb (2020-02-13 19:02:23)

Offline

 

#61 2020-02-14 17:22:17

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

Whoa, I'm sorry to hear you're having trouble sad I should have warned you about that.

WeaselBomb wrote:

The next disaster is that my combination of hardware/software doesn't seem to support the flash chip I chose (S29GL064S70TFI040). It's one of those 16-bit parts that can be run in 8-bit mode

Actually, that's totally not a disaster per sé. Most if not all flash chips today support the JEDEC standard control set, which is what most software (including gbflash) uses.

Somebody really clever at JEDEC decided that instead of keeping the addresses the same (so no matter what mode, write to 0x555), instead they chose to keep the pins the same, so it's always pattern 0x555 at the same pins (An--A0) and extend the pattern to A-1.

WeaselBomb wrote:

I finally noticed that there is a fork of that GBCartFlasher repo that claims to support mx29lv parts, which appears to have identical pinouts to my own chip. I guess if I can compile that and program the Atmega 8515 on my flasher, then it might work?

Pretty much, yes. One needs to shift the patterns by 1 bit to the left and extend it (so copy bit 1 over to bit -1 if you will).
From a casual look at commit 4357c3f, the mx29lv branch seems like an exact fit. Too bad Wenting didn't shift the patterns for ALG16 as well :-/

WeaselBomb wrote:

The README says that it only works with 12 MHz crystals, but that shouldn't be too hard to change back to 6 MHz, right? Worst case, maybe I could desolder the old crystal and drop a 12 Mhz on there.

Don't switch crystals just yet. Depending on the Atmega8515 part (ATmega8515L or ATmega8515) it might not be compatible with a 12 MHz crystal.
Wenting only changed the baud rate prescaler registers, see commit f560c36. Just change them back.
Or you could short E0 to E1 on the GBCardReader. Wenting's software will then use fast mode, which matches standard speed (187.5kBaud) with a 6 MHz crystal. Kraku and Chroost originally coded that in for the serial port version.

WeaselBomb wrote:

Unfortunately, J. Rodrigo didn't include pins to program the Atmega. Guess I will have to solder some in. [...] Guess it's time to cave and get an AVRISP.

Apparently the newer version do: Tindie Shop.
Anyway, there are many affordable programmers that program AVRs. I use fishl's USBasp programmer, which you can get literally anywhere. Works like a charm with avrdude.
Beware that eBay USBasp programmers do not actually change the signal lines between 3V3 and 5V, only supply. But that should be irrelevant as GBCartReader uses 5V anyway.

I wish you the best of luck to get it working. You're literall so~ close smile

Offline

 

#62 2020-02-15 14:19:31

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Programmer just arrived this morning. I was impatient, so I got an Atmel-ICE from Amazon.

Tauwasser wrote:

Don't switch crystals just yet. Depending on the Atmega8515 part (ATmega8515L or ATmega8515) it might not be compatible with a 12 MHz crystal.
Wenting only changed the baud rate prescaler registers, see commit f560c36. Just change them back.

Thank you, that would have taken me forever to find. I've set them back to their previous values.

Tauwasser wrote:

Pretty much, yes. One needs to shift the patterns by 1 bit to the left and extend it (so copy bit 1 over to bit -1 if you will). From a casual look at commit 4357c3f, the mx29lv branch seems like an exact fit. Too bad Wenting didn't shift the patterns for ALG16 as well

Ok, I see where he shifted the patterns in BYTE_PROGRAM, CHIP_ERASE, PRODUCT_ID_ENTRY, PRODUCT_ID_EXIT.
So, I also need to shift the ALG16 patterns? So, for example, shifting the CHIP_ERASE array would result in:

Code:

old: 0x55, 0x55, 0xaa, 0x2a, 0xaa, 0x55, 0x55, 0x55, 0x80, 0x55, 0x55, 0xaa, 0x2a, 0xaa, 0x55, 0x55, 0x55, 0x10,
new: 0xaa, 0xaa, 0xaa, 0x54, 0x54, 0x55, 0xaa, 0xaa, 0x80, 0xaa, 0xaa, 0xaa, 0x54, 0x54, 0x55, 0xaa, 0xaa, 0x10,

For whatever reason, I still can't seem to read my S29GL064. I'll spend some time checking the wiring on my breadboard, I'm a bit stumped at the moment. Right now, I'm just trying to read/write Tetris, so I can exclude the FPGA for now.

I have the #BYTE pin connected to ground, which should leave the device locked to 8-bit mode.
To ensure I'm not crazy, the address bus should be connected to the flash like:
Cart A0 => Flash A-1
Cart A1 => Flash A0
...
Cart A14 => Flash A13
Cart A15 => Flash #CE

Last edited by WeaselBomb (2020-02-15 15:08:04)

Offline

 

#63 2020-02-15 16:33:05

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

Yeah, your address and data connections seem fine. By default the PC software uses ALG16. You would need to use the "-12bit" command line switch when starting the reader software to make it use the ALG12 entries (only the #WR method always uses ALG12, the #WR_AIN method will use whatever the PC software selected).

Do you read anything off the flash chip and it's just not the data you expect (manufacturer etc.) or do you only read 0xFF?

Last edited by Tauwasser (2020-02-15 16:34:12)

Offline

 

#64 2020-02-15 19:11:27

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Tauwasser wrote:

Do you read anything off the flash chip and it's just not the data you expect (manufacturer etc.) or do you only read 0xFF?

Manufacturer ID and Device ID are both returned as 0x90.
It appears to be reading something, just the wrong data is returned. To test DIR polarity, I switched DIR from using /WR to /RD and caused it to read 0xFF, so I changed it back to /WR.

Tauwasser wrote:

only the #WR method always uses ALG12

For now, I've re-wired the breadboard to use /WR instead of AIN, to guarantee ALG12.

I've grounded /OE for the data bus, so it should always be outputting. I didn't think that would cause any problems here, but I could be wrong.
ROM address lines 15-22 are also grounded.

I was playing around with some of the values in those arrays, I hope I didn't accidentally activate some protection on the chip.

EDIT:
Wait a minute, 0x90 is the last byte of the Auto-Select sequence. Something's fishy here...but I don't know what.
Popped in a fresh chip, getting the same 0x90...it's gotta be some small issue I'm having with the firmware I think.

Last edited by WeaselBomb (2020-02-16 13:12:05)

Offline

 

#65 2020-02-16 17:50:19

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

Umm, if you ground the #OE pin on the FLASH chip, you will cause it to always drive the data lines. Then when you write to the chip, you will cause a virtual short circuit, which is bad.
Or were you talking about the #OE pin of the ‎74ALVC164245?

If you read back the same value you write, you might either read a floating bus (capacitance will preserve the value for a little while) or you accidentally did program the FLASH chip and read back the value.
Did you double-check the output-enable logic for U3 pin 25? That should come from your logic. Same goes for #RAM_CS, which must never be asserted (low) as long as the FLASH is targeted for read or write or else contention of the shared data bus will occur.

Last edited by Tauwasser (2020-02-16 18:07:21)

Offline

 

#66 2020-02-16 19:50:10

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

I had originally grounded the /OE on 74ALVC164245. Now, I'm driving it from the FPGA again, using the equation:

Code:

OE <= '0' when (RD = '0' or WR = '0') else '1';

I've actually stripped the circuit down to the bare minimum for debugging, so there's no RAM. The only things connected to the FPGA are RD, WR, and OE (for the 74ALVC). Pins A14:A21 on the flash are grounded, leaving me with A-1:A13. I have swapped AIN for /WR, to force ALG12.

At this point, I can't even erase the flash. The memory changes, but it definitely isn't erased.

I can't find any fault in the firmware, so I guess I've done something stupid here that I'm not seeing. I assume I'm supposed to use Wenting's firmware code as it is, so all I did was revert the pre-scaler registers to work at 6 MHz again. This alone did not seem to work.

Looking at the auto-select sequence in the datasheet, it looks like Wenting has listed the correct addresses (and data values) for x8 mode CHIP_ERASE:

Code:

/** ALG12 */
0x0a, 0xaa, 0xaa, 0x05, 0x55, 0x55, 0x0a, 0xaa, 0x80, 0x0a, 0xaa, 0xaa, 0x05, 0x55, 0x55, 0x0a, 0xaa, 0x10

So, I tried left-shifting those address bytes:

Code:

0x15, 0x54, 0xaa, 0x0a, 0xaa, 0x55, 0x15, 0x54, 0x80, 0x15, 0x54, 0xaa, 0x0a, 0xaa, 0x55, 0x15, 0x54, 0x10

Next, I tried OR-ing the low address bytes with 0x01:

Code:

0x15, 0x55, 0xaa, 0x0a, 0xab, 0x55, 0x15, 0x55, 0x80, 0x15, 0x55, 0xaa, 0x0a, 0xab, 0x55, 0x15, 0x55, 0x10

But, neither of these changes allowed me to erase the flash.
Is it maybe because I'm passing RESET through the voltage translator? I wouldn't think so, the delay is only a few ns.
Is it because the CLKSEL fuses are set incorrectly on the AVR? Right now the fuses are 0xC1 (High), 0x1F (Low), but I think that's correct.

Sorry if I am asking too many stupid questions. Honestly, sometimes I feel like I'm just wasting your time.

Last edited by WeaselBomb (2020-02-16 22:51:02)

Offline

 

#67 2020-02-17 15:56:18

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

WeaselBomb wrote:

I had originally grounded the /OE on 74ALVC164245. Now, I'm driving it from the FPGA again, using the equation:

Code:

OE <= '0' when (RD = '0' or WR = '0') else '1';

Just to make sure: we are talking about the signal that goes to U3 pin 25, right? 2OE in the ‎74ALVC164245 datasheet.
If so, that seems correct. The direction is determined by #WR, which means if #WR == 0 --> GEC to FLASH/RAM, #WR == 1 --> FLASH/RAM to GEC.

WeaselBomb wrote:

I've actually stripped the circuit down to the bare minimum for debugging, so there's no RAM. The only things connected to the FPGA are RD, WR, and OE (for the 74ALVC). Pins A14:A21 on the flash are grounded, leaving me with A-1:A13. I have swapped AIN for /WR, to force ALG12.

A13 and A12 should be don't cares. A11..A-1 are the 12 address bits the FLASH chip should care about.

WeaselBomb wrote:

At this point, I can't even erase the flash. The memory changes, but it definitely isn't erased.

How do you know the memory changed? What kind of measuring/test equipment do you use?
Erasing is kind of a bad test for the connection, because it might fail under many conditions.
Reading the manufacturer codes and CFI array would be better, because the correct data is printed inside the datasheet.

WeaselBomb wrote:

Looking at the auto-select sequence in the datasheet, it looks like Wenting has listed the correct addresses (and data values) for x8 mode CHIP_ERASE:

Code:

/** ALG12 */
0x0a, 0xaa, 0xaa, 0x05, 0x55, 0x55, 0x0a, 0xaa, 0x80, 0x0a, 0xaa, 0xaa, 0x05, 0x55, 0x55, 0x0a, 0xaa, 0x10

So, I tried left-shifting those address bytes:

Code:

0x15, 0x54, 0xaa, 0x0a, 0xaa, 0x55, 0x15, 0x54, 0x80, 0x15, 0x54, 0xaa, 0x0a, 0xaa, 0x55, 0x15, 0x54, 0x10

Next, I tried OR-ing the low address bytes with 0x01:

Code:

0x15, 0x55, 0xaa, 0x0a, 0xab, 0x55, 0x15, 0x55, 0x80, 0x15, 0x55, 0xaa, 0x0a, 0xab, 0x55, 0x15, 0x55, 0x10

But, neither of these changes allowed me to erase the flash.

Yes, the values Wenting put there seem correct. You don't need to shift them anymore.

WeaselBomb wrote:

Is it maybe because I'm passing RESET through the voltage translator? I wouldn't think so, the delay is only a few ns.
Is it because the CLKSEL fuses are set incorrectly on the AVR? Right now the fuses are 0xC1 (High), 0x1F (Low), but I think that's correct.

That should not matter as long as #RESET is deasserted during your testing. The fuses seem okay. They only differ in the EESAVE high fuse from the
original recommendation by Kraku and Chroost.

WeaselBomb wrote:

Sorry if I am asking too many stupid questions. Honestly, sometimes I feel like I'm just wasting your time.

Nah, that's alright. I'm kinda also really bummed that it just won't work for you.
Usually, you just pop these chips in and they instantly work or you spend hours debugging smile So you're definitely not alone in that.

The only other things I can think of (not ruling out anything):

Maybe you have a short circuit somewhere so the address/data lines actually never or only intermediately match.

If you have an oscilloscope, double check the frequency of your control signals so you know that they stay asserted for the recommended times in the datasheet.
If you don't have an oscilloscope, program the ATmega8515 to apply a static pattern that would read or write and carefully measure before and after the voltage translators to know that they are behaving as expected.

I think really the easiest test would be to enter CFI mode, as it's only a single write cycle required and then only reading.

I take it you bought these flash chips from a reputable source that would not sell you fakes or locked chips, right?
Also, you did solder it on correctly, right? I know that's a stupid question, but I've had people debug stuff for days before they realized their chip was 180°
rotated and by some miracle it wasn't an instant heating element wink

Last edited by Tauwasser (2020-02-17 15:58:54)

Offline

 

#68 2020-02-18 18:39:40

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Tauwasser wrote:

Just to make sure: we are talking about the signal that goes to U3 pin 25, right? 2OE in the ‎74ALVC164245 datasheet.

Yep, that's the one

No oscilloscope here, maybe I can borrow one from work later. In the meantime, I've tried a few different patterns on the address and data buses (0xFF, 0xAA, 0x55) and every pin has driven as expected, which makes this even more bizarre. I'm getting my 3v3 power from an Arduino Uno, which I thought might be too weak, but it's rated for up to 150 mA, and I should never be drawing over 100. I've verified all parts are receiving proper voltage, and I can't imagine it would dip below threshold during reads/writes?

Tauwasser wrote:

I take it you bought these flash chips from a reputable source that would not sell you fakes or locked chips, right?

Yeah, all parts used here are sourced from DigiKey.

Tauwasser wrote:

Also, you did solder it on correctly, right?

I've actually got two chips that I've tried, one came pre-assembled on a breakout board from Proto-Advantage, and the other I have placed in a 48-TSOP socket. I tested the corner pin (pin 1) to make sure it was inserted correctly, and it checks out.

I'm so confused, especially since the voltage translators are driving pins correctly. I'm afraid it's going to be a timing issue. I'm still working on it to see what else I can find. At least I'm learning some good C code!

EDIT:
Well, pin 25 on my socket has no connectivity. I took it out of the breadboard and tried for 10 minutes to get a reading on my multimeter, it seems completely disconnected. Time to find my other chip.

Switching to the other flash chip (the one soldered to a breakout board) seemed to work. I can definitely read the manufacturer and device IDs! Erasing also seems to work just fine.
Reading and writing Tetris doesn't completely work yet, though. When I read the data back, most of it matches, but not all.

To enter the auto-select sequence, it has to drive patterns 0x0AAA, 0x0555 on the address bus, and 0xAA, 0x55 on the data bus. To me, that should indicate pins A15 + A11:A0 are driving correctly, and all of the data pins are too? It makes me suspicious of A14:A12...

It sucks that something still doesn't work, but it's good to be back on track.

Last edited by WeaselBomb (2020-02-19 14:59:10)

Offline

 

#69 2020-02-19 16:26:02

Tauwasser
Member
Registered: 2010-10-23
Posts: 148

Re: MBC5 in WinCUPL (problem)

Good thing you found the problem in such a short amount of time (I saw your first edit smile)

Is there a pattern visible in the parts of Tetris that don't match? For instance, if it's every 0x100 bytes, you know A8 is faulty or something like that.
Or if all bytes in a certain range have bit 6 set you know that D6 is most likely not connected all the time etc.

Offline

 

#70 2020-02-19 21:42:29

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

Ok, so it can read/write Tetris perfectly now, after I added decoupling caps to the voltage translator. I had some spare caps laying around, so I tried some electrolytic 0.47uF caps, which seemed to make it much worse. Then I found some ceramic 22 pF caps, which work perfectly. I have a feeling the material mattered more than the capacitance difference, but that's really just a guess.

I didn't think a lack of decoupling would affect those that badly, but when I take the caps away, it starts missing a few bytes here and there.

I couldn't find a single thing about what size decoupling capacitors to use in the datasheet, unless I'm missing something? I was planning on just defaulting to my usual ceramic 0.1 uF caps, but I would like to be sure they'll work. Might have to do some more research I suppose. I wonder if my current decoupling on the PCB is enough? I kinda just guessed based on what these people did (first, second). It looked like using 1-2 caps per translator would suffice.

Last edited by WeaselBomb (2020-02-20 00:06:31)

Offline

 

#71 2020-02-20 18:35:42

gekkio
Member
Registered: 2016-05-29
Posts: 14

Re: MBC5 in WinCUPL (problem)

What are the equations for the data bus transceiver DIR and OE right now?
I've got two ideas of what could be the reason why the extra low-capacitance decoupling is having an effect, but I need to first understand how the data bus buffer control signals are derived.

Offline

 

#72 2020-02-20 19:11:32

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

gekkio wrote:

What are the equations for the data bus transceiver DIR and OE right now?

Right now I have DIR = WR, OE = !RD or !WR

It has been reading/writing Tetris consistently since decoupling caps were added. Before it worked about 5% of the time, now it hasn't failed 12 times in a row.
When I put it in my Gameboy, it acts like there isn't enough power? The screen dims sometimes, the speaker is noisy, and it resets or goes to a black screen after the Nintendo logo. I'm powering the Gameboy from the DC jack, so it isn't low batteries causing it. The only things the Gameboy is powering right now are the voltage translators, everything else is powered by a dedicated 3v3 power supply.

EDIT:
Now I can't seem to erase or reprogram the flash. The manufacturer ID and Device ID are returning 0xC3 and 0x02, which are bytes 0x00 and 0x02 in the Tetris hexcode. I can still read the flash perfectly, but now I'm afraid I may have locked the chip somehow. It just seems very strange that it can use every address and data line to read Tetris, but it can't seem to read the IDs...and since the socket is no good, I can't pop in a new chip and test it out. Maybe I activated some kind of sector protection?

Last edited by WeaselBomb (2020-02-21 11:07:02)

Offline

 

#73 2020-02-21 10:55:36

gekkio
Member
Registered: 2016-05-29
Posts: 14

Re: MBC5 in WinCUPL (problem)

You're only allowed to drive the data bus when rd is low and address is 0x0000-0x7fff / 0xa000-0xbfff. Right now you're causing problems with the work ram which you're sharing the bus with.

That was idea number 1, which is probably the bigger problem of the two smile

Next, how are you deriving chip select for the flash and ram? What are the equations?

Last edited by gekkio (2020-02-21 10:56:08)

Offline

 

#74 2020-02-21 11:09:57

WeaselBomb
Member
Registered: 2018-03-06
Posts: 85
Website

Re: MBC5 in WinCUPL (problem)

gekkio wrote:

Right now you're causing problems with the work ram which you're sharing the bus with.

Actually there's no RAM in this circuit, just flash. No MBC, either. The FPGA is only in place to drive /OE on the voltage translator. I'm really just trying to prove this circuit works before adding the other components, so reading/writing/booting a 32 KB game seemed like a good first test.

gekkio wrote:

Next, how are you deriving chip select for the flash and ram? What are the equations?

flash chip select is A15

Now I can't seem to erase the chip at all. Manufacturer ID and Device ID are showing as 0xC3 and 0x02, and looking at the Tetris code, those are the values at addresses 0x00 and 0x02, which is where those IDs are supposed to be read from...I'm wondering if I've done something very wrong here. It's almost like it can't enter AutoSelect mode any more.

Offline

 

#75 2020-02-21 13:10:11

gekkio
Member
Registered: 2016-05-29
Posts: 14

Re: MBC5 in WinCUPL (problem)

If you're just using the cartridge with a flasher, there's probably no problem. But you also said this:

> When I put it in my Gameboy, it acts like there isn't enough power

I'm not surprised since you're causing bus conflicts and fighting with the work RAM. Your circuit is *not* safe for use with a real GB.

Now, idea number 2 is basically this: never have floating inputs when dealing with CMOS chips. The data bus between the GB (or flasher) and the transceiver seems to be ok, but your 3.3V-side data bus is not guaranteed to have a valid data value at all times. If you only have a flash chip in place and A15 is the flash chip CS, your 3.3V-side data bus inputs are floating at all times except when the address bus contains an address that is lower than 0x8000 and the flash chip is driving a value on the data bus.

PS. One annoying thing about ‎74ALVC164245 is that the data sheet specifies extra restrictions about the two power supply lines. In practice, powering up the 3.3V side before the 5V side seems the violate data sheet requirements. This is one of the reasons why I prefer 74LVC8T245 instead...it simply doesn't care

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson