Avoiding SWRAM Corruption on Power Down

discuss both original and modern hardware for the bbc micro/electron
Post Reply
User avatar
KenLowe
Posts: 1632
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Avoiding SWRAM Corruption on Power Down

Post by 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
256K RAM IC
MAX6366 Supervisor IC
MAX6366 Supervisor IC
Attachments
MAX6368-1389214.pdf
MAX6366 Datasheet
(179.06 KiB) Downloaded 14 times
User avatar
daveejhitchins
Posts: 6110
Joined: Wed Jun 13, 2012 6:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Avoiding SWRAM Corruption on Power Down

Post by 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.
User avatar
1024MAK
Posts: 10488
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Avoiding SWRAM Corruption on Power Down

Post by 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
User avatar
KenLowe
Posts: 1632
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Avoiding SWRAM Corruption on Power Down

Post by KenLowe »

daveejhitchins wrote:
Mon Nov 16, 2020 11:37 am
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
/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...
User avatar
KenLowe
Posts: 1632
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Avoiding SWRAM Corruption on Power Down

Post by KenLowe »

1024MAK wrote:
Mon Nov 16, 2020 12:13 pm
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.
User avatar
KenLowe
Posts: 1632
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Avoiding SWRAM Corruption on Power Down

Post by KenLowe »

1024MAK wrote:
Mon Nov 16, 2020 12:13 pm
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.
User avatar
KenLowe
Posts: 1632
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Avoiding SWRAM Corruption on Power Down

Post by KenLowe »

1024MAK wrote:
Mon Nov 16, 2020 12:13 pm
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);
User avatar
1024MAK
Posts: 10488
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Avoiding SWRAM Corruption on Power Down

Post by 1024MAK »

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

Mark
Post Reply

Return to “8-bit acorn hardware”