Avoiding SWRAM Corruption on Power Down

[KenLowe]

Hi folks. Me again

For those following progress of my IntegraB V2 project:

viewtopic.php?f=3&t=19392
viewtopic.php?f=3&t=19429

With the help of some very knowledgeable and helpful people on this forum (you know who you all are!!!) I managed to get both Shadow and SWRAM / ROMs working reliably on my board. However, currently I am having to use a bunch of 32K RAM ICs instead of the 512K IC that is soldered onto the board.

The 512K IC does work to a degree, and I can both read / write to it without any issue. However, if I try to run code from it, it's not so happy. For example, if I load BASIC into one of the banks (using Martin Barrs EELOAD utility), it loads and verifies fine. On reset it even responds correctly and returns with the

Code: Select all

BBC Computer 32K
Acorn 1770 DFS
BASIC
>

prompt. However if I try to execute a BASIC command (eg P. ~PAGE) it just returns random rubbish on the screen. If I disable the 512K IC, and use a bunch of 32K ICs instead it works just fine.

On my 512K IC, I've added a MAX6366 Supervisory IC to the /CE line to try and avoid data corruption on power down, and I suspect this is the source of the problem. I've wired A13 into the watchdog input, but on reflection that was probably not the wisest choice. I picked that line because it was easy to route on the PCB.

So, before getting the soldering iron out, my question is - should this work as I've designed, or have I missed something altogether here? Do I just need to use a different address line (like A0) which is probably going to be toggling more frequently, or should I scrap this idea altogether and just get the CPLD to drive /CE directly?

Once again TIA.

256K RAM IC

MAX6366 Supervisor IC

[daveejhitchins]

What does Out (pin 6) supply, from the MAX6366? It should ONLY supply the RAM! It looks as if it may power more? Maybe I'm not seeing the whole picture!

Dave H.

[1024MAK]

So the first thing to do is to try to work out if the problem is the MAX6366, the 512k byte SRAM chip or the control logic for the 512k byte SRAM chip.

Some more modern SRAM chips don’t behave the same as older lower capacity SRAM chips. Especially if they are fast versions. So don’t assume the control signal inputs do what you think they do. Carefully read the datasheet and check any truth tables and check that your control logic does not allow any undesirable states.

If this was my project, for the time being, for testing, I would take the MAX6366 out of the control path for the SRAM chip /CE input, to see if this makes any difference.

I’m not sure I would be happy relying on one high address line for a watchdog, what happens if the program is in a loop somewhere, such that A13 does not change state?

Normally watchdogs are used for embedded systems or other systems where they will ALWAYS be running code that WILL toggle a signal that the watchdog system monitors. With general purpose systems you have to be rather careful with your choice.

Mark

[KenLowe]

What does Out (pin 6) supply, from the MAX6366? It should ONLY supply the RAM! It looks as if it may power more? Maybe I'm not seeing the whole picture!

Dave H.

Hi Dave,

The V2 IntegraB has an onboard 512k RAM IC, and all 16 SWR banks have access to a dedicated 16k area of memory on this IC. This RAM is battery backed via the MAX6366.

The V2 IntegraB is very configurable, which makes it more complicated to explain, but I will try...

• It is possible to individually switch between ROM banks 0..3 on the mainboard and RAM banks 0..3 on the 512k IC with jumpers on the IntegraB board
• The IntegraB has 8 x 16k ROM sockets assigned to ROM banks 8..15. Again, it is possible to individually switch between these 8 ROM banks and RAM banks 8..15 on the 512k IC with jumpers on the IntegraB board.
• With jumpers on the IntegraB board it is possible to use 4 of the 8 x 16k ROM sockets for 4 x 32k ROMs
• Similarly, with jumpers on the IntegraB board it is possible to use 4 of the 8 x 16k ROM sockets for 4 x 32k RAMs.
• With yet more jumpers, it is possible to select between battery backed on non battery backed power if using 32k RAM in any of the 4 ROM sockets. If using battery backed power for any of this RAM, then this is provided via the MAX6366. This is fed via the 5VO signal you will have spotted on the circuit diagram.
• Banks 4..7 are dedicated SWRAM banks on the 512k RAM IC. There are no equivalent ROM sockets for these 4 banks.

Phew. I hope that made sense.

Anyway, moving on to report what I've now done. I've bypassed the MAX6366 and have wired the CPLD /CE signal directly onto the RAM IC, and that's cured the issues I was having:

/CE on my RAM IC

SWRAM and Shadow RAM are all now running perfectly from the 512k RAM IC, and I can switch in and out ROM banks as necessary. Each of the 16 RAM banks can also be individually write protected!

I would still like to get the MAX6366 working, but that's lower priority for me.

Next up is trying to figure out why the RTC won't play...

[KenLowe]

So the first thing to do is to try to work out if the problem is the MAX6366, the 512k byte SRAM chip or the control logic for the 512k byte SRAM chip.

Some more modern SRAM chips don’t behave the same as older lower capacity SRAM chips. Especially if they are fast versions. So don’t assume the control signal inputs do what you think they do. Carefully read the datasheet and check any truth tables and check that your control logic does not allow any undesirable states.

If this was my project, for the time being, for testing, I would take the MAX6366 out of the control path for the SRAM chip /CE input, to see if this makes any difference.

I’m not sure I would be happy relying on one high address line for a watchdog, what happens if the program is in a loop somewhere, such that A13 does not change state?

Mark

You must have posted just as I was finishing off my previous post. I've actually done as you recommended, and bypassed the MAX6366, and it's completely fixed the issue.

And I completely agree with you about relying on a single address line for the watchdog. I'm fairly certain that's where it's failing.

[KenLowe]

I’m not sure I would be happy relying on one high address line for a watchdog, what happens if the program is in a loop somewhere, such that A13 does not change state?

Normally watchdogs are used for embedded systems or other systems where they will ALWAYS be running code that WILL toggle a signal that the watchdog system monitors. With general purpose systems you have to be rather careful with your choice.

I'm thinking of using the Phi2 clock instead. I can't think of any downside of using that signal, and it should be relatively easy to route on the board.

[KenLowe]

I’m not sure I would be happy relying on one high address line for a watchdog, what happens if the program is in a loop somewhere, such that A13 does not change state?

Normally watchdogs are used for embedded systems or other systems where they will ALWAYS be running code that WILL toggle a signal that the watchdog system monitors. With general purpose systems you have to be rather careful with your choice.

Further to my last post, I've been doing further work on this, and instead of using A13 (or Phi2), I've temporarily wired in nRDS, as it's a very simple routing change, and it seems to work just fine. The MAX6366 datasheet indicates that the watchdog has a 1.6s time out. Can anyone see an issue with using nRDS for this function? Am I ever likely to see nRDS stall for >1.6s under normal operation? I only really want to see this watchdog signal come into operation when the beeb powered is off, and the RAM is being powered by the backup battery.

For info, nRDS is derived from the following equation:

Code: Select all

nRDS = !( RnW & Phi2);

[1024MAK]

That should be fine. The processor should be reading an instruction far more often than that!

Mark