Disabling the system while flashing

[barnacle]

Pulling a logic output to a state other than that which it is currently is always a bad idea. Most logic families these days use totem pole logic where the output is connected to one or the other rail (or neither, for three-state outputs) and it's only this latter stage that can be safely controlled by something else.

An AND gate is perhaps a better approach (without seeing the rest of the circuit and understanding what it's supposed to do, it's hard to be prescriptive).

Neil

EDIT: re your edit: it's still a bad idea. The datasheet doesn't mean the current is limited to 4mA; it means that trying to take more than 4mA will damage the output transistor.

[speculatrix]

barnacle wrote:

Pulling a logic output to a state other than that which it is currently is always a bad idea.

Dammit. Just when I thought I had the answer.

Here's the decode logic I'm working with:

From re-reading the 65C02 datasheet, it seems that pulling BE low puts the address and data buses into high-Z, and does the same for RWB. So I'm assuming that the MCU can take over those signals. If so, all I need to know is if it's safe to hold the PHI2 signal low with the MCU. The signal's coming from a bog-standard oscillator can.

[BigDumbDinosaur]

speculatrix wrote:

barnacle wrote:

Pulling a logic output to a state other than that which it is currently is always a bad idea.

Dammit. Just when I thought I had the answer.

Here's the decode logic...

Suggestion: in your schematic(s), components such as the 74HCT00 should be drawn as individual gates for clarity, instead of as a rectangle with connections.  For example:

With the gates individually depicted as in above, it is much easier for the casual reader to discern what the circuit is expected to do.

Quote:

From re-reading the 65C02 datasheet, it seems that pulling BE low puts the address and data buses into high-Z, and does the same for RWB.  So I'm assuming that the MCU can take over those signals.

That is correct.  You do need to carefully consider your timing to assure that the C02 high-Zs the buses and RWB before the MCU takes control so as to avoid any contention.  Also, be sure to consider that BE is an asynchronous signal, which means driving it low immediately high-Zs everything without regard to the MPU’s state during a cycle.  Furthermore, while the time required for the MPU to respond to BE going high is a defined specification, the response time to BE going low is not.

Quote:

If so, all I need to know is if it's safe to hold the PHI2 signal low with the MCU.  The signal's coming from a bog-standard oscillator can.

Once the CO2 is no longer driving the buses and RWB, you are free to halt the Ø2 in either phase, as long as you are using a WDC C02 with a static core (W65C02S).  If you are using an older dynamic core WDC part (no S in the part number) or a non-WDC part, you cannot halt Ø2 in the low phase and expect the MPU to maintain internal state.  I recommend you halt Ø2 in the high phase while the C02’s SYNC output is high, which indicates an opcode fetch cycle.

Unless you are using a clock oscillator with an output-enable control pin, you need to run the oscillator’s output through a gate so you can control Ø2.  In order to be able to halt Ø2 in the high phase, you can use a two-input NAND gate, with one input driven by the oscillator and the other controlled by the MCU.  If the MCU-controlled input is driven high, the gate’s output will oscillate.  If the MCU-controlled input is driven low, the gate will output a continuous high, which effectively halts Ø2 in the high phase.  For best performance, the NAND gate should be 74AC to produce low, single-digit transition times as specified for the WDC MPUs’ clock input.

Something else to consider is that after the MCU rewrites the flash ROM, you may have to trigger a hard reset of the C02 so it starts from the beginning with the new ROM code.  You can’t assume that you can just resume the MPU after rewrite—the code at the address currently in the MPU’s PC may have changed, likely invalidating the MPU’s current state.

Incidentally, the value of R3 in your most-recent schematic is a little low—I’d increase it to 470 or 560 ohms.  No sense in driving the heck out of the power-on LED.

[speculatrix]

Thanks for the info. I think I'm slowly getting to a solution.

[speculatrix]

Okay, just in case there's anyone still playing along at home, here's what I've arrived at.

This is the clock circuit:

There's a new NAND gate (an AHC part with an average speed of 7ns). The two inputs are the ouput of the oscillator and a signal from an MCU GPIO I'm calling CLK_CTRL. This line has a pullup.

If I understand this correctly, in its default state, this will just invert the clock signal, which is fine. But if the MCU pulls CLK_CTRL low, the PHI2 signal will remain high.

Now for the next bit. This is the ROM/RAM decode (we're only concerned with the right half of the chip. The left half is for RAM and it doesn't matter what happens to that because we're going to be doing a full reset anyway).

With BE pulled low by the MCU, the address bus, data bus and RWB will be tristated, so the MCU can take control of those. With the PHI2 kept high and RWB set to LOW by the MCU, /READ_EN will be high, which is what we want most of the time. Should I want to perform a read of the flash (eg, for verification) the MCU can take the RWB high, making /READ_EN low. (FYI, the write-enable pin of the flash is under the sole control of the MCU).

[BigDumbDinosaur]

speculatrix wrote:

This is the ROM/RAM decode...

BigDumbDinosaur wrote:

Suggestion: in your schematic(s), components such as the 74HCT00 should be drawn as individual gates for clarity, instead of as a rectangle with connections.

Arrggg!!!  My eyeballs are bleeding trying to read that second schematic.  I’m not even going to try to figure out that one.

As for the clock circuit, that will work...with an asterisk.  The 74AHC1G00’s prop time is not the critical element—it is substantially lower than what is needed to stay with the clock oscillator.  The concern is the gate’s output rise/fall time, which is comparable to the 74HC equivalent and does not meet WDC’s specs for the clock input (5ns max).  That may, or may not, cause some timing trouble, depending on how fast you plan to run this thing.

R13 is only necessary if whatever is controlling CLK_CTRL is incapable of driving it high.  If you do need R13, you need a much lower value—22K will make the circuit noise-sensitive and vulnerable to the effects of parasitic capacitance.  Something in the range of 3.3K would be much better.

[Yuri]

BigDumbDinosaur wrote:

speculatrix wrote:

This is the ROM/RAM decode...

BigDumbDinosaur wrote:

Suggestion: in your schematic(s), components such as the 74HCT00 should be drawn as individual gates for clarity, instead of as a rectangle with connections.

Arrggg!!!  My eyeballs are bleeding trying to read that second schematic.  I’m not even going to try to figure out that one.

For the rest of us humans:

[speculatrix]

BigDumbDinosaur wrote:

The concern is the gate’s output rise/fall time, which is comparable to the 74HC equivalent and does not meet WDC’s specs for the clock input (5ns max).  That may, or may not, cause some timing trouble, depending on how fast you plan to run this thing.

It's strolling along at 1MHz. When you say 5ns, is that total rise/fall time or rate (per volt)? I've found an LVC part that does 5ns/V, but that's the fastest I've yet discovered.

BigDumbDinosaur wrote:

R13 is only necessary if whatever is controlling CLK_CTRL is incapable of driving it high.  If you do need R13, you need a much lower value—22K will make the circuit noise-sensitive and vulnerable to the effects of parasitic capacitance.  Something in the range of 3.3K would be much better.

CLK_CTRL is being driven by the MCU, which has plenty of oomph to drive it high. However, my intention is that (for the most part) when the MCU is actively doing flashing operations it will set its GPIOs as inputs to (effectively) tristate them.

[J64C]

Personally, I’d lock in the CLK_CTRL as either High or Low as 22K pull up will be a pretty low switch speed. But in reality, wouldn’t really matter too much having said that.

Bonus points for the series resistor, from my point of view, that will keep the clock nice and clean, with minimal ringing.

[BigDumbDinosaur]

speculatrix wrote:

BigDumbDinosaur wrote:

The concern is the gate’s output rise/fall time, which is comparable to the 74HC equivalent and does not meet WDC’s specs for the clock input (5ns max).  That may, or may not, cause some timing trouble, depending on how fast you plan to run this thing.

When you say 5ns, is that total rise/fall time or rate (per volt)?  I've found an LVC part that does 5ns/V, but that's the fastest I've yet discovered.

5ns rail-to-rail.

[Michael]

I'm reminded of San Bergmans' Raspberry Pi EPROM Emulator project where he isolates the ROM from the system while holding the reset line low during emulator programming mode. I thought about using a 40-pin uC instead of a Raspberry Pi but never started the project. Probably not very practical solution for your use case. Too many parts and you probably wouldn't want those three 74HC541's left in-circuit when switching back to normal 'run' mode operation.

[speculatrix]

Michael wrote:

you probably wouldn't want those three 74HC541's left in-circuit when switching back to normal 'run' mode operation.

Yeah, I am trying to reduce chip count! I currently have a board being fabbed that uses a modified version of my initial approach using an MCU (ATmega328PB) and a flash chip. I incorporated a number of suggestions in this thread, particularly with regard to how to handle decoding signals etc. We'll see how well that works out when the boards arrive.

In the meantime, I played with the idea of using an MCU as a ROM, but decided in the end that the AVRs I'm used to probably don't have the oomph to meet the 65C02's timing requirements. I have started looking at an STM32 chip (specifically, the 250MHz STM32H523CE), but that's a whole new ecosystem for me, so I'm still on the early part of the learning curve with that.

[BigDumbDinosaur]

speculatrix wrote:

In the meantime, I played with the idea of using an MCU as a ROM...

Seems to me as though using a ROM as a ROM would be less hassle.   Either one has to be reprogrammed if you wish to replace the firmware with something new.

[Michael]

speculatrix wrote:

In the meantime, I played with the idea of using an MCU as a ROM...

I'm sure you could make that work if the uC is fast enough. A think a Pi Pico could be a good candidate. When using a PIC @ 16 MIPS there were only 16 PIC instruction cycles to work with within a 1-MHz 6502 clock cycle which was not enough. My solution, again, was a RAM only system with a ROM image store. One nice thing about using a PIC uC for the ROM image store is that the PIC can self-program its Flash memory so it's relatively easy to update the ROM image in-circuit (no programmer required).

[BigDumbDinosaur]

Michael wrote:

One nice thing about using a PIC uC for the ROM image store is that the PIC can self-program its Flash memory so it's relatively easy to update the ROM image in-circuit (no programmer required).

It should be possible to accomplish the same thing with a 39SF0x0 flash device by harnessing the MPU to act as the programmer.  There would be some code in the firmware that, when called, copies a flashing function into RAM, along with a suitable I/O driver, and then runs the function to read from a data link, e.g., a TIA-232 interface.  The incoming data stream, following some sort of integrity check, would be written to the 39SF0x0.