Help - Implementing Shadow RAM in CPLD

discuss both original and modern hardware for the bbc micro/electron
User avatar
daveejhitchins
Posts: 6087
Joined: Wed Jun 13, 2012 6:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by daveejhitchins »

You could try a higher value resistor e.g. lower the charging current - and strap a 3V9 Zener across the battery - Although zeners aren't that accurate so maybe a 1N4001 (or just any diode - 1N4148/BAT52 etc. anything to drop the Voltage!) in series with the feed from the battery to your RTC.

Dave H.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

daveejhitchins wrote:
Wed Nov 25, 2020 8:19 am
You could try a higher value resistor e.g. lower the charging current
I went for 150R, based on the discussion in this thread:

viewtopic.php?f=3&t=13590&p=269287#p265614
daveejhitchins wrote:
Wed Nov 25, 2020 8:19 am
and strap a 3V9 Zener across the battery - Although zeners aren't that accurate so maybe a 1N4001 (or just any diode - 1N4148/BAT52 etc. anything to drop the Voltage!) in series with the feed from the battery to your RTC.
I did toy with this idea earlier, but backed away when I read the following comment in the RTC datasheet. However, I'm fairly sure the RTC wouldn't really know if you're using a diode. It's only interested in a stable voltage, and for the voltage to be within spec, so I may give the series diode a try - unless someone can tell me why that's a bad idea:
DS12885 Datasheet wrote:VBat - Pin 20: Connection for a Primary Battery. (DS12885 Only.) Battery voltage must be held between the minimum and maximum limits for proper operation. If a backup supply is not supplied, VBAT must be grounded. Connect the battery directly to the VBAT pin. Diodes in series between the VBAT pin and the battery may prevent proper operation. UL recognized to ensure against reverse charging when used with a lithium battery.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

KenLowe wrote:
Wed Nov 25, 2020 8:39 am
daveejhitchins wrote:
Wed Nov 25, 2020 8:19 am
You could try a higher value resistor e.g. lower the charging current
I went for 150R, based on the discussion in this thread:

viewtopic.php?f=3&t=13590&p=269287#p265614
daveejhitchins wrote:
Wed Nov 25, 2020 8:19 am
and strap a 3V9 Zener across the battery - Although zeners aren't that accurate so maybe a 1N4001 (or just any diode - 1N4148/BAT52 etc. anything to drop the Voltage!) in series with the feed from the battery to your RTC.
I did toy with this idea earlier, but backed away when I read the following comment in the RTC datasheet. However, I'm fairly sure the RTC wouldn't really know if you're using a diode. It's only interested in a stable voltage, and for the voltage to be within spec, so I may give the series diode a try - unless someone can tell me why that's a bad idea:
DS12885 Datasheet wrote:VBat - Pin 20: Connection for a Primary Battery. (DS12885 Only.) Battery voltage must be held between the minimum and maximum limits for proper operation. If a backup supply is not supplied, VBAT must be grounded. Connect the battery directly to the VBAT pin. Diodes in series between the VBAT pin and the battery may prevent proper operation. UL recognized to ensure against reverse charging when used with a lithium battery.
The series diode didn't work. With nothing connected to the VBat input, I'm measuring about 4.5v on the pin and the RTC does not communicate. If I then take this input and tie it down to Gnd it works fine. Adding the diode prevents the internal voltage on VBat from being pulled down to a low enough level for the RTC to start communicating.

The Zener may be the next best option. I'll have a look at that now.
User avatar
daveejhitchins
Posts: 6087
Joined: Wed Jun 13, 2012 6:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by daveejhitchins »

KenLowe wrote:
Wed Nov 25, 2020 9:33 am
The series diode didn't work. With nothing connected to the VBat input, I'm measuring about 4.5v on the pin and the RTC does not communicate. If I then take this input and tie it down to Gnd it works fine. Adding the diode prevents the internal voltage on VBat from being pulled down to a low enough level for the RTC to start communicating.

The Zener may be the next best option. I'll have a look at that now.
That doesn't make sense! What do you mean by "With nothing connected to the VBat input"? You can't do that - Vbat needs connecting to ground or the battery.

The Vbat pin in an input! Data sheet says "Battery voltage must be held between 2.5V and 4V for proper operation". I don't see how placing a diode between the battery and the Vbat pin can't work! All you're doing is losing the Voltage across the diode! What diode did you use? I'd try a 1N4148 - with such a low current (you can check how much by reading your RAM data sheets) you'll only lose up to 600mV (probably less!) which should be enough to get you out of trouble.

Dave H.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

daveejhitchins wrote:
Wed Nov 25, 2020 12:03 pm
KenLowe wrote:
Wed Nov 25, 2020 9:33 am
The series diode didn't work. With nothing connected to the VBat input, I'm measuring about 4.5v on the pin and the RTC does not communicate. If I then take this input and tie it down to Gnd it works fine. Adding the diode prevents the internal voltage on VBat from being pulled down to a low enough level for the RTC to start communicating.

The Zener may be the next best option. I'll have a look at that now.
That doesn't make sense! What do you mean by "With nothing connected to the VBat input"? You can't do that - Vbat needs connecting to ground or the battery.

The Vbat pin in an input! Data sheet says "Battery voltage must be held between 2.5V and 4V for proper operation". I don't see how placing a diode between the battery and the Vbat pin can't work! All you're doing is losing the Voltage across the diode! What diode did you use? I'd try a 1N4148 - with such a low current (you can check how much by reading your RAM data sheets) you'll only lose up to 600mV (probably less!) which should be enough to get you out of trouble.

Dave H.
Sure, but if you leave the input it floating, and measure what's on the pin you get a voltage. I discovered that when I connected the diode and it didn't appear to do anything. When I measured the voltage upstream of the diode I got the battery voltage. Downstream of the diode I got a voltage that was higher than the battery voltage which initially didn't appear to make any sense. Disconnecting the diode didn't change that. So, although it's an input there must be some internal circuitry that's causing that to happen. Attaching a fixed voltage direct to the input pulls that pin voltage down and allows it to work. With the series diode in circuit it doesn't allow this to happen. I'm sure that's why the datasheet states:
DS12885 Datsheet wrote:Diodes in series between the VBAT pin and the battery may prevent proper operation.
Does that make sense, or am I still talking rubbish?

I used a BAT43 diode, although I could easily test again with a 1N4148. I've got plenty of those!

Edit: I've just tried with a 1N4148 and it hasn't made any difference. What I did notice, though, is that just connecting a meter to the measure the voltage on the pin causes the RTC to start responding. Remove the meter and it stops again. This happens either with the VBat pin floating, or connected to the battery via the diode. Connecting the battery direct to VBat works as long as the voltage is below about 4v (I think it might be that the voltage at VBat must be more that 0.7v below Vcc, but that's a bit of a guess. Vcc is currently sitting at 5.0v and VBat is sitting at about 4.2v and it's still working, although I expect it to stop working shortly, once VBat reaches about 4.3v)
dp11
Posts: 1228
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by dp11 »

have you got any decoupling on vbat and vdd ?
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

I'm sure I'm just stating what you already know here....

The DS12885/7 are designed use a simple non-rechargable 3V lithium coin-cell, like a CR2032, and the valid range of Vbat is 2.5V to 4.0V

You are using a 3.6V 150mAh Varta battery with a charging circuit consisting of a 68R resistor and a B5819W diode with a Vf of 0.6-0.9v. So when fully charged, that battery is reaching ~4.3v, which is too high for the DS12885.

Placing a diode in series with Vbat doesn't work, because there is nothing stopping the Vbat pin floating higher than the battery voltage (the diode becomes reverse biased and stops conducting).

You could prevent this diode becoming reverse biased by adding a high(ish) value resistor (e.g. 47K) between Vbat and 0V, but this will slowly discharge the battery. The discharge rate would be 75uA so ~2000 hours to completely discharge a 150mAh battery. This may be acceptible, but is a bit of a hack. But fine for testing the bus interface.

A second option is to add a second B5819W into the charging circuit, so the battery reaches a max of ~3.6V.

A third option is to replace the battery by a 3V cell (and adapt the charing circuit appropriately), but that depends on what the mimumum voltage is for data retention in the RAM.

What RAM are you using? The schematic indicates a IS61C5128AS.

Dave
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

dp11 wrote:
Wed Nov 25, 2020 1:06 pm
have you got any decoupling on vbat and vdd ?
I do have on Vdd, but not on VBat. However, I do currently have a big lump of battery on VBat!
hoglet wrote:
Wed Nov 25, 2020 1:07 pm
I'm sure I'm just stating what you already know here....

The DS12885/7 are designed use a simple non-rechargable 3V lithium coin-cell, like a CR2032, and the valid range of Vbat is 2.5V to 4.0V

You are using a 3.6V 150mAh Varta battery with a charging circuit consisting of a 68R resistor and a B5819W diode with a Vf of 0.6-0.9v. So when fully charged, that battery is reaching ~4.3v, which is too high for the DS12885.

Placing a diode in series with Vbat doesn't work, because there is nothing stopping the Vbat pin floating higher than the battery voltage (the diode becomes reverse biased and stops conducting).

You could prevent this diode becoming reverse biased by adding a high(ish) value resistor (e.g. 47K) between Vbat and 0V, but this will slowly discharge the battery. The discharge rate would be 75uA so ~2000 hours to completely discharge a 150mAh battery. This may be acceptable, but is a bit of a hack. But fine for testing the bus interface.

A second option is to add a second B5819W into the charging circuit, so the battery reaches a max of ~3.6V.

A third option is to replace the battery by a 3V cell (and adapt the charing circuit appropriately), but that depends on what the minimum voltage is for data retention in the RAM.

What RAM are you using? The schematic indicates a IS61C5128AS.

Dave
Thanks for the detailed reply, and thanks for confirming my observations on placing a diode in series with VBat.

Yes, I have been pondering the various options. I'm actually using a low power CY62148ELL-45ZSXI (I'll update the schematic to reflect that), with a minimum Data Retention voltage (Vdr) of 2v, so a non rechargeable button cell is certainly an option.

The simplest solution is probably to stick another diode into the charging circuit, in series with the existing diode. However, I did quite like the option of adding a Zener diode / resistor arrangement on the battery output to clamp the voltage at 3v3, and I've already updated the schematic to reflect this. I probably also need to add a bit of decoupling to this, if I do go down this route. Is there a particular downside to the Zener barrier option?
KenLowe wrote:
Wed Nov 25, 2020 12:17 pm
I think it might be that the voltage at VBat must be more that 0.7v below Vcc, but that's a bit of a guess. Vcc is currently sitting at 5.0v and VBat is sitting at about 4.2v and it's still working, although I expect it to stop working shortly, once VBat reaches about 4.3v
The VBat voltage has crept up to 4.27v, and Vcc remains at 5.00v. Unsurprisingly, at these levels, the RTC has stopped communicating again.
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

The zener option sounds workable as well.

Definitely worth prototyping though!
User avatar
daveejhitchins
Posts: 6087
Joined: Wed Jun 13, 2012 6:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by daveejhitchins »

OK . . . Solution . . . Use a non rechargeable Lithium (3V or 3.6V) - You'll have at least 5 years out of it. Problem solved.

As Hoglet has said - it must have internal circuitry that allows the pin to float, reverse biasing any diode in series.

Dave H.
User avatar
danielj
Posts: 8538
Joined: Thu Oct 02, 2008 5:51 pm
Location: Manchester
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by danielj »

daveejhitchins wrote:
Wed Nov 25, 2020 2:30 pm
OK . . . Solution . . . Use a non rechargeable Lithium (3V or 3.6V) - You'll have at least 5 years out of it. Problem solved.
Added bonus is no potentially leaky battery soldered to the board waiting to barf its guts up in the future :) A number of bits of hardware I'm in possession of would definitely have preferred to have been furnished with a coin cell rather than rechargeable :D
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

Thanks for all the advice, guy. It's very much appreciated. I think I've been convinced on the button cell option - particularly once I started to think a bit more about the Zener barrier option. My initial thoughts were to go with a 3v3 barrier, but thinking about it a bit more, I realise that doesn't make much sense for a nominal 3.6v battery! Sensibly, it would need to be above 3.6v (eg 3v9 as Dave H suggested earlier), which reduces the working margin available. So non rechargeable battery it is, then!

Having identified and solved the VBat problem, I'm still being frustrated with the DS12885 that's soldered onto my V2 board. It still refuses to communicate, even with the VBat input now within tolerance (I've tried with it tied to Gnd). On this board I had previously cut the data bus tracks, so I could insert some inline resistors between the data buffer and the RTC, but that didn't seem to make much difference, and in further testing I wasn't sure if cutting the tracks and patching in resistors may have made things worse. So I built up a second V2 board last night to see if that would work any better. On this board, I'm using a remotely mounted 3v button cell, and I've cut the specifically designed link bar to disconnect the 5v feed to the charging circuit. Unfortunately, this hasn't made any difference and this RTC doesn't work either. Again, and as with the previous V2 board, if I disable the onboard RTC (by just not pulsing the AS & DS lines) and hook up a remote RTC (using 'spare' I/O from the CPLD to drive AS and DS) it works just fine. I'm going to spend some more time tomorrow looking into this.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

Got the logic analyser hooked up today. Firstly, very simple code:

Code: Select all

.start
LDA #&55
STA &FE38
LDA #&AA
STA &FE38
JMP start
In the CPLD, RTC_AS and RTC_DS are defined as follows:

Code: Select all

wire   FE3x		= (bbc_ADDRESS[15:4] == 12'hFE3);
assign RTC_AS  = FE3x && (bbc_ADDRESS[3:2] == 2'b10) && !RnW && Phi2; // &FE38..B -> Address Strobe
assign RTC_DS  = FE3x && (bbc_ADDRESS[3:2] == 2'b11);  // &FE3C..F -> Data Strobe
And this is what happens with a trigger on rising edge of RTC_AS. According to the RTC datasheet, the address is latched on falling edge of AS. It appears that &FE is what's actually getting latched. Note that the bus has currently got pull up via 4k7 resistor network. Any thoughts? How do I stop that final &FE being latched into the RTC?
Writing &55 and &AA to &FE38
Writing &55 and &AA to &FE38
I'm guessing D0 is a little bit noisy and the logic analyser is perhaps picking up some false pulses (hence the occasional &FE instead of &FF?). Although, that doesn't have a bearing on the fact the the RTC address is being latched when the data bus has nothing on it?
Last edited by KenLowe on Sat Nov 28, 2020 1:10 pm, edited 1 time in total.
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

Ken,

The Logic Analyzer trace suggests you have sampled at 20KHz.

I assume that's incorrect?

But what was the sampling clock speed?

(You should be running at 12MHz, the fastest the FX2 will sample 16-bits at)

Dave
Last edited by hoglet on Sat Nov 28, 2020 1:11 pm, edited 1 time in total.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

Duh #-o

If I run it at 4MHz is that fast enough?
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

KenLowe wrote:
Sat Nov 28, 2020 1:11 pm
Duh #-o

If I run it at 4MHz is that fast enough?
You want to run it as fast as possible, which is 12MHz (in 16-bit wide mode).
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

Right. Not sure what you mean by the 16 bit wide mode, but here a much more sensible capture. I'll now try writing some data as well through the data strobe:
More sensible capture...
More sensible capture...
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

KenLowe wrote:
Sat Nov 28, 2020 1:30 pm
Not sure what you mean by the 16 bit wide mode, but here a much more sensible capture.
That's much better.

The FX2 board can capture between 1 and 8 signals at upto 24MHz. However, if you capture between 9 and 16 signals, the max capture rate drops to 12MHz.

Dave
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

hoglet wrote:
Sat Nov 28, 2020 1:48 pm
That's much better.

The FX2 board can capture between 1 and 8 signals at upto 24MHz. However, if you capture between 9 and 16 signals, the max capture rate drops to 12MHz.

Dave
Ah. Ok, I understand. Because I'm capturing 12 signals, I'm using the 16 bit mode (and therefore limited to 12MHz).

Right, this time I'm running the following endless loop:

Code: Select all

.start
LDA #&20
STA &FE38 ;Strobe in address &20
LDA #&55
STA &FE3C ;Strobe in value &55 to address &20
LDA #&20
STA &FE38 ;Strobe in address &20
LDA #&AA
STA &FE3C ;Strobe in value &AA to address &20
BNE start ;and loop
RTS
and here's the result. Looks like I need to tie Phi2 into the RTC_DS signal:
Writing &55 / &AA to RTC address &20
Writing &55 / &AA to RTC address &20
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

This time, I've tied RTC_DS to Phi2:

Code: Select all

wire   FE3x		= (bbc_ADDRESS[15:4] == 12'hFE3);
assign RTC_AS  = FE3x && (bbc_ADDRESS[3:2] == 2'b10) && !RnW && Phi2; // &FE38..B -> Address Strobe
assign RTC_DS  = FE3x && (bbc_ADDRESS[3:2] == 2'b11) && Phi2;  // &FE3C..F -> Data Strobe
Not exactly what I expected based on the previous trace. I had hoped the falling edge of RTC_DS would happen marginally earlier than the rising edge of R/nW, but that hasn't happened here. Looking at timing diagram in the datasheet, I'm pretty sure the falling edge of RTC_DS needs to happen before the rising edge of R/nW, but that's not what's happening. Am I reading the timing diagram right? Any thoughts on how best to correct this?
RTC_AS now tied to Phi2
RTC_AS now tied to Phi2
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

KenLowe wrote:
Sat Nov 28, 2020 2:15 pm
Looking at timing diagram in the datasheet, I'm pretty sure the falling edge of RTC_DS needs to happen before the rising edge of R/nW, but that's not what's happening. Am I reading the timing diagram right? Any thoughts on how best to correct this?
The RnW signal on a 6502 will always lag the falling edge of Phi2, usually by about 50ns.

They only look like they are happening at the same time because the logic analyzer is only sampling at 12MHz (83ns).

If you put the two siignals on a scope, you should be able to measure the delay more accurately.

Dave
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

hoglet wrote:
Sat Nov 28, 2020 2:53 pm
KenLowe wrote:
Sat Nov 28, 2020 2:15 pm
Looking at timing diagram in the datasheet, I'm pretty sure the falling edge of RTC_DS needs to happen before the rising edge of R/nW, but that's not what's happening. Am I reading the timing diagram right? Any thoughts on how best to correct this?
The RnW signal on a 6502 will always lag the falling edge of Phi2, usually by about 50ns.

They only look like they are happening at the same time because the logic analyzer is only sampling at 12MHz (83ns).

If you put the two siignals on a scope, you should be able to measure the delay more accurately.

Dave
That might actually explain what's going wrong, then. The R/nW signal is wired direct from the CPU, whereas the RTC_AS & RTC_DS signals are generated via the CPLD. Could it be that there is sufficient delay in the CPLD to cause an issue? I'm using a 10ns CPLD. As you suggest, I'll wire it up to my scope and get a better view of the edges.
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

KenLowe wrote:
Sat Nov 28, 2020 3:24 pm
That might actually explain what's going wrong, then. The R/nW signal is wired direct from the CPU, whereas the RTC_AS & RTC_DS signals are generated via the CPLD. Could it be that there is sufficient delay in the CPLD to cause an issue? I'm using a 10ns CPLD. As you suggest, I'll wire it up to my scope and get a better view of the edges.
I would be very surprised if the there was a timing issue there.

I would expect the CPLD (generating RTC_DS) to be much faster than a SY6502A (generating RnW).

Dave
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

Here's a trace with a single write of &AA to address &20, followed by multiple reads from address &20. I tend to believe the value &D1 is genuinely what is held at address &20. The value I read stays the same, regardless of what I try to write. If I switch to address &21, I consistently read the value &71, and if I switch back to address &20 again I get the value &D1 again:
Single write, followed by multiple reads
Single write, followed by multiple reads
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

That suggests it's the RTC write that is failing.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

hoglet wrote:
Sat Nov 28, 2020 3:34 pm
That suggests it's the RTC write that is failing.
It does indeed.

Another odd thing. The results vary depending on whether I have pull up or pull down on the data bus. The data bus is currently terminated with 4k7 resistors. Here's what happens:

With pull up:
Test 1
Strobe in address &20
Strobe out data: Result &D1
Strobe in address &20
Strobe out data: Result &D1
Strobe in address &20
Strobe out data: Result &D1
Strobe in address &20
Strobe out data: Result &D1
...

Test 2
Strobe in address &20
Strobe out data: Result &D1
Strobe out data: Result &FF
Strobe out data: Result &FF
Strobe out data: Result &FF
...

With pull down:
Test 1
Strobe in address &20
Strobe out data: Result &85
Strobe in address &20
Strobe out data: Result &85
Strobe in address &20
Strobe out data: Result &85
Strobe in address &20
Strobe out data: Result &85
...

Test 2
Strobe in address &20
Strobe out data: Result &85
Strobe out data: Result &00
Strobe out data: Result &00
Strobe out data: Result &00
...

Edit: Just swapped out the 4k7 for 1k0, but I get exactly the same results as above.
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

I think that's expected. The data sheet says:
An address strobe must immediately precede each write or read access.
(i.e. it doesn't suggest that multiple "data strobe only" cycles are allowed, nor do the timing diagrams show that).

Can you write a program that dumps all of the registers, say once a second?

That would prove that read cycles are working correctly, as you should be at to see the RTC clock registers counting.

Dave
User avatar
hoglet
Posts: 9807
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by hoglet »

Sorry, ignore the last post.

I missed the fact that the Test 1 results were different.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

hoglet wrote:
Sat Nov 28, 2020 4:36 pm
I think that's expected. The data sheet says:
An address strobe must immediately precede each write or read access.
(i.e. it doesn't suggest that multiple "data strobe only" cycles are allowed, nor do the timing diagrams show that).
Without going down another rabbit hole here, I have noticed that on a system where I can communicate with the RTC, multiple 'data strobe only' access does actually repeatedly give the same value with out having to continually precede it with the same address strobe. So long as you've done at least one address strobe.

The real odd thing that I noticed on this test system is that Test 1 (which did precede a data strobe with an address strobe) gave a different result, depending on whether I used pull up or pull down.
hoglet wrote:
Sat Nov 28, 2020 4:36 pm
Can you write a program that dumps all of the registers, say once a second?

That would prove that read cycles are working correctly, as you should be at to see the RTC clock registers counting.
I can certainly write a program to read the clock registers (addresses 00..09). However, you actually need to write to the RTC to start the clock in the first instance - via DV0, 1 & 2 (bits 4, 5 & 6) of control register A (which is also RTC address A), so I won't see any registers counting until it's been initialised.

Edit: Sorry, just notice you made a post as I was writing this one.
User avatar
KenLowe
Posts: 1626
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Help - Implementing Shadow RAM in CPLD

Post by KenLowe »

hoglet wrote:
Sat Nov 28, 2020 2:53 pm
KenLowe wrote:
Sat Nov 28, 2020 2:15 pm
Looking at timing diagram in the datasheet, I'm pretty sure the falling edge of RTC_DS needs to happen before the rising edge of R/nW, but that's not what's happening. Am I reading the timing diagram right? Any thoughts on how best to correct this?
The RnW signal on a 6502 will always lag the falling edge of Phi2, usually by about 50ns.

They only look like they are happening at the same time because the logic analyser is only sampling at 12MHz (83ns).

If you put the two signals on a scope, you should be able to measure the delay more accurately.

Dave
Hi Dave (or anyone else who might be able to help!),

The datasheet states that during a write operation, 'the trailing edge of DS causes the device to latch the written data', and if I'm reading the data sheet correctly I need a minimum 10ns between RTC_DS falling and RnW rising (tRWH) in order to correctly latch in the data? If the 6502 RnW signal typically lags the falling edge of Phi2 by about 50ns, the timing seems quite marginal, or is that quite normal? I will check that on the scope shortly.

I was also toying with the idea of adding a couple of inverters into the RTC RnW line to see if the extra propagation delay would make any difference. However, that would take a little bit of effort, so wanted to first check if it's a worthwhile exercise, or if I'd just be wasting my time?
Post Reply

Return to “8-bit acorn hardware”