Interrupts returning to wrong address

[barrym95838]

BillG wrote:

Could that be the problem?

I was totally thinking the same thing. If you don't put a "throwaway" byte after BRK, your ISR will RTI into the second byte of the following instruction.

[sci4me]

barrym95838 wrote:

BillG wrote:

Could that be the problem?

I was totally thinking the same thing. If you don't put a "throwaway" byte after BRK, your ISR will RTI into the second byte of the following instruction.

Good catch. While it is true that I was missing the throwaway byte (I had falsely assumed ca65 inserted it automatically when using the `brk` mnemonic), that wasn't the actual problem; the difference between the correct return address and the one found on the stack by `rti` is much than a single byte. Furthermore, this issue occurs on hardware interrupts as well. :/

Unfortunately I haven't actually had time to really work on this but I'm hoping I'll have time today. Still need to try tying some unused inputs to ground (on some of the address decoding logic chips) and changing the RAM circuit slightly, as mentioned in previous posts.

[sci4me]

Chromatix wrote:

Looking at the circuit diagrams up-thread, I would note that the canonical method of generating /CS, /OE and /WE signals is:

1: /CS for each device should depend only on address lines, /VP, and (for the '816) VDA and VPA. It should not be qualified by Phi2; thus two gates should be removed from the RAM /CS chain.

2: /OE and /WE should be generated as ~(R/W & Phi2) and ~(~(R/W) & Phi2) respectively. They will then produce a pulse on one or the other line on every cycle, during a time interval when the address and /CS signals will all be stable.

At 1MHz the speed of memory devices is not likely to be an issue. Ensuring that relative timing requirements are met, however, is still just as important. If /WE is active at any instant when the address or data lines are not stable, then you can expect incorrect data to be written to the wrong places.

Well, unfortunately even this didn't fix it. I put the RAM and a 74HC00 on a breadboard and wired it up as you described; it worked just as it had before. Everything seemed fine except that the wrong return address is on the stack in the ISR.
And when I say wrong, I mean, off by hundreds of bytes. Strangely, the number of bytes it's off by seems to vary depending on the code I'm using. Haven't really noticed any pattern to it yet, but this is definitely a thing.

Would it be helpful if I uploaded images of the PCB itself? i.e. a screenshot from KiCad of the top and bottom copper layers?

[floobydust]

Sure, a picture and such are worth... well, as they say. I've seen some odd issues with some static RAM over the years. Had a new one that was defective... nothing worked... turns out page $03 had some bits stuck on the early bytes, where I keep interrupt vectors.

Also, are you bypassing the chips effectively? CMOS logic tends to switch faster, so bypassing is critical (and the location of the bypass caps). One last thought... have you used a multimeter to ring out all of the address and data lines plus the rest of the access lines to the RAM chip? Lastly, have you tried another RAM chip??

[GARTHWILSON]

sci4me wrote:

Would it be helpful if I uploaded images of the PCB itself? i.e. a screenshot from KiCad of the top and bottom copper layers?

It couldn't hurt. Screenshots are probably always the best way, rather than posting CAD files for CAD packages that others don't have. Gerber files are pretty universal, but even then, not everyone would have or want to install a gerber viewer.

[barrym95838]

sci4me wrote:

Well, unfortunately even this didn't fix it.

Since JSR and RTS seem to work okay (right?), I'm left wondering if the hardware is somehow gagging on three consecutive stack writes but not two ... I have insufficient hardware chops to support my theory, but I thought I'd just toss it out there for someone to snipe at.

[sci4me]

floobydust wrote:

Sure, a picture and such are worth... well, as they say. I've seen some odd issues with some static RAM over the years. Had a new one that was defective... nothing worked... turns out page $03 had some bits stuck on the early bytes, where I keep interrupt vectors.

Also, are you bypassing the chips effectively? CMOS logic tends to switch faster, so bypassing is critical (and the location of the bypass caps). One last thought... have you used a multimeter to ring out all of the address and data lines plus the rest of the access lines to the RAM chip? Lastly, have you tried another RAM chip??

I _think_ the bypassing I have should be sufficient, but... when I was designing the board, for whatever reason, I only ended up adding caps for some of the chips, instead of what I wish I'd done: all of them. It's not impossible that it's an issue, but it baffles me that the symptom would be so consistent if that were the cause, not that it's impossible. As for checking continuity, embarrassingly, I haven't actually. Will do so shortly. And, I haven't tried another RAM chip, so I'll be sure to order more of them next time I'm ordering parts (which has been all too frequent lately, lol). However, this is the same RAM chip I was using on the breadboard version, so I at least know it was working correctly before.

barrym95838 wrote:

sci4me wrote:

Well, unfortunately even this didn't fix it.

Since JSR and RTS seem to work okay (right?), I'm left wondering if the hardware is somehow gagging on three consecutive stack writes but not two ... I have insufficient hardware chops to support my theory, but I thought I'd just toss it out there for someone to snipe at.

Yep, JSR and RTS are working just fine. And I share this suspicion too.

PCB Front

PCB Back

[floobydust]

Well, a few things stick out:

1- You really do need more bypass caps... at least a 0.1uF on every IC chip. Also, as the board has some size, I would strategically add some additional 100uF caps around the board to maintain a low impedance on the supply traces.

2- Power supply traces are very thin... and some are quite long. There's an inconsistency with them as well... some are wider and some are quite thin.

3- The 7805 regulator, is it getting hot? Do you have a heatsink on it? Granted, the CMOS chips are all pretty low power, but the 7-segment displays can draw some current. What is the supply voltage to the board? Remember that the 7805 has to be some voltage level above it's regulated output to ensure proper regulation.

I would have likely gone for a 4-layer board with a ground and +5 plane. This would make things much easier for routing power. My small (3.8" x 2.5") Pocket SBC has 12- 0.1uF bypass caps plus 3- 63uF polymer caps for 7 chips total. It's also a 4-layer board and is dead quiet on noise. I'm a big fan of excess bypassing. Also, if you open sockets, you can hide the bypass caps under the IC itself. I do this on most of my PCBs, it's very effective for decoupling as you can get the bypass cap very close to the supply pin.

Hopefully adding some additional bypass caps will help, and perhaps swapping out the RAM as well for a test. Good luck on sorting it out.

[sci4me]

floobydust wrote:

Well, a few things stick out:

1- You really do need more bypass caps... at least a 0.1uF on every IC chip. Also, as the board has some size, I would strategically add some additional 100uF caps around the board to maintain a low impedance on the supply traces.

2- Power supply traces are very thin... and some are quite long. There's an inconsistency with them as well... some are wider and some are quite thin.

3- The 7805 regulator, is it getting hot? Do you have a heatsink on it? Granted, the CMOS chips are all pretty low power, but the 7-segment displays can draw some current. What is the supply voltage to the board? Remember that the 7805 has to be some voltage level above it's regulated output to ensure proper regulation.

I would have likely gone for a 4-layer board with a ground and +5 plane. This would make things much easier for routing power. My small (3.8" x 2.5") Pocket SBC has 12- 0.1uF bypass caps plus 3- 63uF polymer caps for 7 chips total. It's also a 4-layer board and is dead quiet on noise. I'm a big fan of excess bypassing. Also, if you open sockets, you can hide the bypass caps under the IC itself. I do this on most of my PCBs, it's very effective for decoupling as you can get the bypass cap very close to the supply pin.

Hopefully adding some additional bypass caps will help, and perhaps swapping out the RAM as well for a test. Good luck on sorting it out.

1. Will definitely be taking this advice for rev2!
2. I should've mentioned that although I have power traces in the pictures I posted, I actually have a ground plane on the bottom and a power plane on the top. I have no idea if making the top a power plane vs. a ground plane was a "good" or "bad" idea, but that's just what I ended up doing. So, those traces aren't really representative of the actual PCB.
3. The 7805 does get a little warm but since I raised the resistance for the 7-segment LEDs (by a lot), it's not "hot". I have a heatsink and sil pad coming in the mail tomorrow. I am using a 2A, 12V wall adapter.

As for going with a 4-layer board, I have no opposition to it, but I wanted to see if I could pull it off with just two layers; I feel like (as someone who isn't an electrical engineer) it's probably fine.

Now, here's some exciting news: I tried something I should've tried days ago: pushing some bytes onto the stack before the interrupt occurs. I haven't tested this yet with hardware interrupts, but with a BRK, that actually "fixes" it! I haven't tried every possible combination, but I do know that pushing just a single byte is enough to get it working.
So, definitely going to check all the address lines for continuity...

So, it's not solved per se, but for now it looks like as long as the stack pointer is not $FF, this issue doesn't occur. But like I said, I haven't tried every possible value for the stack pointer.

EDIT: As far as I can tell, this failure only occurs when the stack pointer of $FF.

EDIT 2: Okay so, bad news: I wrote a program that uses a timer from a VIA to count up by seconds on the 7-segment LEDs, and it is now working, even if the stack pointer starts out at $FF, so. I am very confused.

[floobydust]

Well, unfortunately, Version 1.00 usually shows up some problems... which get corrected with Version 1.01, who knew. Here's a link to my C02 Pocket SBC.... some decent pics showing the PCB with and without the chips installed, so you can see how I mounted the bypass underneath the IC sockets:

viewtopic.php?f=4&t=4988

Based on your last post, if you have less trouble after the stack pointer is moved down, that could mean you have some issues with your RAM chip. Instead of pushing data onto the stack, just change your initialization of the stack... meaning, instead of setting it at $FF, set it to $F0 or $E0 and seen if things change. I would also urge you to solder some bypass caps on the bottom of the board and just directly tack them to Ground and VCC at each chip.

[Dr Jefyll]

floobydust wrote:

Based on your last post, if you have less trouble after the stack pointer is moved down, that could mean you have some issues with your RAM chip.

True, but it could also indicate a missing connection somewhere (which seems more likely than a bad RAM chip). Really, it's time to do those continuity checks!

-- Jeff

[BigEd]

Here's a software idea (continuity checking obviously being a very good hardware idea: you need to look both for opens and for shorts)
- fill page one with known values, not all the same and not equal to the low byte of the address
- do the BRK and RTI
- compare page one contents with the initial content perhaps by printing out and looking

For bonus points
- inside the ISR, copy page one content to another page, and have a good look at it later.

Perhaps also
- fill page one as before
- do the JSR and RTS
- compare page one

[Dr Jefyll]

I agree you need to look both for opens and for shorts.

As for the idea of a software-based test to find hardware faults, the idea seems flawed. The test itself could easily behave erroneously (as a result of the hardware fault).

I don't think there's any substitute for checking the darn wiring. Manually, I mean.

[BigEd]

You're right, it's possible that a given software test will be inconclusive or difficult to explain. And you might need more analytical effort to interpret the results. But I think it can often be useful. And if you hadn't the equipment for further hardware investigation, you might explore with software as a matter of practicality. Perhaps while you wait for equipment to arrive...

... but mainly I wanted to post my idea!

[floobydust]

It can be difficult to debug a new system... especially when you have a new hardware design and are writing the software for it. When something doesn't work, you need to be able to determine if the hardware or software is the problem. In some cases, it helps to have some known simple software that can run on a minimal hardware base. Just as long as you have the minimal required hardware and configure the I/O in the software, it "should" work. If not, then you can be pretty certain that you have a hardware problem.

Some years ago, I cobbled a minimal BIOS/Monitor together for basic testing of a 65C02, a (working) 65(c)51 and at least 2KB of ROM and at least 2KB of RAM. ROM must be addressed at the top of memory and RAM at the bottom of memory. Some others on the forum have used this code to verify that the base hardware is functioning. In short, if this code won't work, you have a hardware problem.

I'll suggest that Sci4me grab my Micromon code from my Github page. All that's needed for his system would be to yank out the chips that aren't being used (65C22s, latches, LED drivers, etc.) and ensure the base I/O address for the 6551 is changed to his and ensure the IRQ line from the 6551 is connected to the IRQ line of the CPU.

Second, which is likely to be a problem, is... I think he's using a WDC W65C51 ACIA... which has the Xmit bug, so no proper code will run it for transmit. If this is the case, then I would likely suggest he secure an older Rockwell R6551 (or R65C51) for testing. Short of this, the only other option would be to use a delay routine for sending characters.