Disabling the system while flashing

[speculatrix]

Forgive me, but I'm going to ask a question I asked before, but with a different emphasis this time. I need to know if my logic is sound.

I had this idea of using flash memory to replace an EEPROM. Lots of people had lots of great ideas many of which, I confess, I found too intimidating for my skillset. So I've decided to plough on with the idea of an MCU and flash chip.

Here's the thing: I want to be able to reflash the chip without turning off the computer. But, of course, the flash chip is connected to certain system-wide signals, notably D0-D7, A0-A13 and signals I've called /ROM_ENABLE and /READ_EN.

The latter two are controlled via NAND gates.

/ROM_ENABLE has A14 and A15 as its inputs and its output goes to the ROM's /CE.
/READ_EN has R/W and PHI2 as inputs and its output goes to /OE on the ROM.

Now, my plan is this:

When the MCU goes into flash writing mode, it will take the 65C02's BE and RDY lines low, halting the processor and setting its bus pins to high impedance. The MCU can directly control A14 and A15 and the /ROM_ENABLE lines, so I don't see any problem there.

I want the MCU to also directly control the ROM's /OE pin (aka /READ_EN). But ... I'm not clear on what happens with R/W when the CPU's halted and the clock will still be ticking. So I'm not sure what will happen with that NAND and whether it might interfere with the /READ_EN signal coming from the MCU. (I want to be able to read from the flash during flashing operations for verification purposes.)

So, could I solve this problem by having the MCU hold the PHI2 line low during flashing?

Would appreciate all input (pun intended).

[BigDumbDinosaur]

speculatrix wrote:

Forgive me, but I'm going to ask a question I asked before, but with a different emphasis this time. I need to know if my logic is sound...I'm not clear on what happens with R/W when the CPU's halted and the clock will still be ticking...

Internally, the MPU will hold RWB in its current state when RDY is driven low, as the MPU’s internal clock will be halted in the high phase.  In other words, if the MPU was in the middle of a write cycle when RDY was driven low, RWB will be held low for the duration.  BTW, the same effect may be achieved by stopping the clock generator while in the high phase.

The MPU’s RWB output will go high-Z and float when BE is driven low.  That could potentially cause trouble with the logic that is used to generate separate /OE and /WR strobes.  If you are going to do what you are planning, you have to take steps to assure the read/write logic doesn’t ever see a floating signal and unintentionally drive /WR low.

Note that BE is an asynchronous signal and if driven low while the MPU is still running, will likely lead to a major malfunction.  I think for what you are doing, you’d be better off stopping Ø2 at the end of the high phase and then pull BE low.  Once you have finishing flashing, reverse the sequence to restart the MPU.

[barnacle]

Regarding BE - I did demonstrate to my satisfaction that BE could be clocked at the same rate as PH0 without issues (I wanted a DMA for video). However, that was at a low clock speed - under 2MHz, and I never investigated further.

Neil

[speculatrix]

BigDumbDinosaur wrote:

Note that BE is an asynchronous signal and if driven low while the MPU is still running, will likely lead to a major malfunction.  I think for what you are doing, you’d be better off stopping Ø2 at the end of the high phase and then pull BE low.  Once you have finishing flashing, reverse the sequence to restart the MPU.

All good info, thanks. I'm not concerned with having the computer restart from where it left off. My plan was to have the MCU pulse /RESET low to invoke a reboot after the end of the flashing sequence.

[gfoot]

speculatrix wrote:

All good info, thanks. I'm not concerned with having the computer restart from where it left off. My plan was to have the MCU pulse /RESET low to invoke a reboot after the end of the flashing sequence.

In that case you could just wire BE to /RESET and hold them both low throughout the procedure - you can leave RDY pulled high. I did something similar in my ARM-based computer, holding it in the reset state while preloading the RAM from ROM, and then releasing it at the end.

[speculatrix]

gfoot wrote:

In that case you could just wire BE to /RESET and hold them both low throughout the procedure - you can leave RDY pulled high. I did something similar in my ARM-based computer, holding it in the reset state while preloading the RAM from ROM, and then releasing it at the end.

I'm still concerned about what happens to the flash chip's /OE. Presumably the R/W line will be floating while the clock will be oscillating. That suggests to me that the output from the NAND, which is connected to the flash's /OE, will be, um, unpredictable. The MCU needs to be able to take full control over the /OE input.

[gfoot]

speculatrix wrote:

gfoot wrote:

In that case you could just wire BE to /RESET and hold them both low throughout the procedure - you can leave RDY pulled high. I did something similar in my ARM-based computer, holding it in the reset state while preloading the RAM from ROM, and then releasing it at the end.

I'm still concerned about what happens to the flash chip's /OE. Presumably the R/W line will be floating while the clock will be oscillating. That suggests to me that the output from the NAND, which is connected to the flash's /OE, will be, um, unpredictable. The MCU needs to be able to take full control over the /OE input.

For sure, you need to make sure that doesn't happen - but note that BDD said above that RWB will be high-Z in this case, so while you're holding BE low your MCU can just drive RWB itself, e.g. driving it low so that the glue logic holds /OE high, disabling your flash's output. If you also make your glue logic know how to drive the flash's /WE (like it does for RAM) then you may not even need the MCU to have direct control of that - but we sort of talked about that before I think, and perhaps you prefer to ensure that the flash's /WE is only asserted when you really want it to be, during flashing operations.

[BigDumbDinosaur]

speculatrix wrote:

gfoot wrote:

In that case you could just wire BE to /RESET and hold them both low throughout the procedure - you can leave RDY pulled high. I did something similar in my ARM-based computer, holding it in the reset state while preloading the RAM from ROM, and then releasing it at the end.

I'm still concerned about what happens to the flash chip's /OE. Presumably the R/W line will be floating while the clock will be oscillating. That suggests to me that the output from the NAND, which is connected to the flash's /OE, will be, um, unpredictable. The MCU needs to be able to take full control over the /OE input.

You need to clarify what you mean by “R/W line.”  Are you referring to the 65C02’s RWB output or something else?

Meanwhile, you could arrange your read/write glue logic so /OE stays high when reset is low, regardless of the Ø2 phase.  BTW, is there a schematic somewhere of your proposed design?

That said, why would you need a µcontroller to redo the firmware?  You already have a microprocessor (the 65C02) at your disposal.  If you are using something such as a 39SF010 for your firmware, it is possible to rewrite all or part of it in situ by loading a suitable bit of code into RAM—in fact, that code can come from the firmware itself.  As long as that rewrite code doesn’t require the services of anything in the firmware, e.g., an I/O driver, you can completely replace the firmware, followed by a reset.

[Yuri]

gfoot wrote:

For sure, you need to make sure that doesn't happen - but note that BDD said above that RWB will be high-Z in this case, so while you're holding BE low your MCU can just drive RWB itself, e.g. driving it low so that the glue logic holds /OE high, disabling your flash's output. If you also make your glue logic know how to drive the flash's /WE (like it does for RAM) then you may not even need the MCU to have direct control of that - but we sort of talked about that before I think, and perhaps you prefer to ensure that the flash's /WE is only asserted when you really want it to be, during flashing operations.

To me it makes the most sense that the micro-controller would have the same R/W, address and memory lines as the 6502 (65816) and then would mimic all the same signals that the 6502 while it keeps the BE line held low. In this way all the glue logic could be kept as is w/o needing to redo any of that logic else where.

The only thing I could think that could be an issue is that MAYBE there's some very brief period where you've sent the BE line low, and the uController hasn't yet taken over the lines; or perhaps the other way around where both the 6502 and uController try to drive the bus at the same time; but this seems like it would be the same if this was a uController or a DMA controller, or anything else requesting access to drive the bus for a while.

The high-Z situation seems like it could be resolved with one or more pull-up resistors; however, I wonder if that's overkill and probably would create more problems than it would solve.

The contention issue also seems like it would be overkill to solve, at least on a hobbyist circuit; the time period is likely to be short. Perhaps on a professional level design there might be a consideration on what it might do to the longevity of the parts?

[drogon]

Yuri wrote:

gfoot wrote:

For sure, you need to make sure that doesn't happen - but note that BDD said above that RWB will be high-Z in this case, so while you're holding BE low your MCU can just drive RWB itself, e.g. driving it low so that the glue logic holds /OE high, disabling your flash's output. If you also make your glue logic know how to drive the flash's /WE (like it does for RAM) then you may not even need the MCU to have direct control of that - but we sort of talked about that before I think, and perhaps you prefer to ensure that the flash's /WE is only asserted when you really want it to be, during flashing operations.

To me it makes the most sense that the micro-controller would have the same R/W, address and memory lines as the 6502 (65816) and then would mimic all the same signals that the 6502 while it keeps the BE line held low. In this way all the glue logic could be kept as is w/o needing to redo any of that logic else where.

This is how my Ruby boards work. Memory is essentially shared in a mutually exclusive manner.

Quote:

The only thing I could think that could be an issue is that MAYBE there's some very brief period where you've sent the BE line low, and the uController hasn't yet taken over the lines; or perhaps the other way around where both the 6502 and uController try to drive the bus at the same time; but this seems like it would be the same if this was a uController or a DMA controller, or anything else requesting access to drive the bus for a while.

You need to make sure the 65xx is properly halted before pulling BE low. At least I did and I resolved this in my systems as follows:

There is no ROM. It's all RAM, but this way could be used to re-flash EEPROM if needed.

At power on or reset time, the µC holds the 65xx in reset, pulls BE low and pokes the bootstrap into RAM.

The µU then tristates itself, releases BE and releases Reset. The 65xx springs into life!

After that, the 65xx is the overall controller and signals to the µC that it needs "something" by writing the code into the mutually exclusive shared RAM and executing WAI. Meanwhile the µC has been waiting on the RDY signal and when it gets it, (when WAI is executed) it pulls BE low, attaches itself to the RAM and does what's needed. It restores everything and fires off an interrupt to the 65xx which wakes it up and it carries on.

Quote:

The high-Z situation seems like it could be resolved with one or more pull-up resistors; however, I wonder if that's overkill and probably would create more problems than it would solve.

Because I only access 8 address lines (A0:7) I have 10K pull-ups on A8:15. This gives me a "window" from $00FF00 through $00FFFF. (My "latch" for the top 8 address lines in the '816 board holds them high when it sees BE going low).

This has worked exceptionally reliably for some years now.

-Gordon

[barnacle]

Looking at my LV8153 serial loading SBC, it's using essentially the same approach: on reset, a flip flop holds both reset and be low; the 8153s do their magic, and when complete, reset and be are set high again. The significant difference is that the processor is _always_ reset after reloading code.

R/~W is pulled high at the processor to ensure that all the decoding using it works without issue in the floating state; the actual ~write signal to the ram is AND gated with a signal which is low when the 8153s are busy, and high once they're done; i.e. the rest of the life of the program until the next reset.

Neil

[Michael]

I'm curious about the schematic and memory map. Could you use a pin on the uC to map a portion of the large Flash ROM with upload and programming routines into the I/O space temporarily and let the 6502 do some of the work?

Also curious how a uC based solution would provide separate address and data lines. I tried both I2C and SPI 16-bit I/O expander chips in the past for a Flash Programmer project but ended up just using a pair of 20¢ 74HC574's which were faster and used less uC pins.

[speculatrix]

Wow, that was a lot of information all at once!

I will be looking at how I can use the 65C02, but that will be a future project. I want to see this one through first. One complication is that user I/O is via serial and the serial routines are in the ROM. So I'd probably need to write a RAM-based application with its own serial routines that somehow usurp those of the system. But that's a future headache.

I've attached a PDF with schematics. These are a work in progress - ie, unfinished.

The MCU I'm using (ATmega4809) has plenty of GPIOs, so I can mimic as many CPU/system signals as I want. When I referred to R/W earlier, I did indeed mean the RWB CPU signal. The decoding logic I'm concerned about (as far as ROM is concerned) involves A14, A15, R/W and PHI2. It's easy enough for me to control the first three with the MCU. The fourth (PHI2) isn't a CPU signal, which is why I was considering just holding it low.

[gilhad]

speculatrix wrote:

So I'd probably need to write a RAM-based application with its own serial routines that somehow usurp those of the system.

Depends on your style of reading the serial:
- if you call routine and it just somehow reads data and waits for full incomming message to be read (or as much as was requested, maybe one char), then you youst copy such routine into RAM and adjust all needed jumps/branches inside
- if your ROM routine use some interrupts, then modify the interrupt table to jump into RAM table, where is jump to the ROM routine written on boot and when flashing came, rewrite the pointer to your RAM code.

[speculatrix]

While I'm digesting the replies, there is one thing about which I realise my knowledge is sorely lacking.

In the following diagram, I will have a situation where the /READ_EN signal will be held high by the decoding logic (a 74HCT00).

But I may want to pull it low using the MCU GPIO to enable reading (for example, to verify code). But it feels to me that the GPIO might receive excessive current. Would it? Would a power-limiting resistor help, and if so, where and what value?

EDIT: Never mind. Just did what I should have done in the first place and read the datasheet. The 74HCT00 can only source about 4mA which the MCU can easily handle.