In-Circut Programming of a flash

[willie68]

Maybe the topic has already been discussed, then I would be grateful for a link.

I'm looking for a way to program the Flash (or EEPROM) in my SBC directly from my PC. At the moment this is only possible by pysically moving the Flash from/to SBC/Programmer. That's why I've already screwed a ZIF adapter onto the SBC.
I thought maybe i could do something with an Arduino.
- Disconnect the processor with /BE and /RDY. (via Arduino)
- Set A14, A15 accordingly (so that the other ICs are not addressed).
- Then one could program the flash with an Arduino with A0..12 (or 13 for my flash) and D0..7 and the corresponding other required signals and voltages.
- Then switch everything to high impedance again and restart the SBC with /RESET.

Had someone already implemented something like this?
Maybe there is already a Arduino based Flash programmer.

[Proxy]

if it's something like an SST39SF0x0 Flash then the system could be designed around it, give the CPU the ability to directly erase and program it without external hardware (ie the CPU gets the command to re-flash the chip, it loads a small program into RAM, jumps to it, ereases the chip, loads a new program via Serial/SD/whatever, and then locks the chip again before resetting itself or waiting for the user to power cycle it).

one alternative (if your SBC has a serial connector) is to write a small Serial Bootloader (like Arduinos have) so you don't need to touch the ROM again to try out programs as they can simply be loaded into and executed from the SBC's RAM. that's what i did for both my 65c02 and 65c816 SBCs and it works great and allows for a pretty fast developement cycle without wearing out the Flash.

[hoglet]

Following on from the previous post, here's some sample code that programs a 39SF010A in circuit:
https://github.com/hoglet67/FpgaUtils/b ... /flash.inc

The code is part of a utility ROM to support an Acorn Atom RAM/ROM board.

You do need control of all the address lines going into the FLASH ROM.

In this example A0..A11 come from the CPU and A16..A12 come from a 5-bit register (called ROM Latch)

Dave

[willie68]

Proxy wrote:

…
one alternative (if your SBC has a serial connector) is to write a small Serial Bootloader (like Arduinos have) so you don't need to touch the ROM again to try out programs as they can simply be loaded into and executed from the SBC's RAM. that's what i did for both my 65c02 and 65c816 SBCs and it works great and allows for a pretty fast developement cycle without wearing out the Flash.

This is than a hen-egg-problem. So in the end, when i have the bootloader everything is fine. But at least that’s what I’m trying to do.
And yes, I’ll use an xxxF0x0 Flash. I’m thinking about using an Arduino, because I have several available, with some 595 for addressing as an Adapter socket. I’m just working on the serial connection, so it should not take so long, as I got another solution.

[plasmo]

If you have a CPLD in your SBC design, then you can put a small (32-64 bytes) bootstrap ROM in CPLD that allows you to load the flash programming software which, in turn, loads the actual code in RAM then writes to flash.
Bill

[floobydust]

I've been using the Atmel EEPROM (AT28C256 and AT28BV256) for my SBCs. I implemented the ability to program them insitu within my Monitor code years ago. It's quite simple to do... just make sure the code that writes to the EEPROM is running from RAM. The same can be done for the ST series of flash memory as well.

I also have the ability to send and receive Xmodem CRC to/from the terminal app (either Putty on Windoze or Serial on OSX). The Xmodem receive automagically detects and downloads S-Record (S19) files, which is what I assemble and link using WDC Tools. This gives me the ability to write code, download it, test it and also write it to the EEPROM without removing it from the SBC. I also wrote a couple small utilities that will update the BIOS and the Monitor code as well... but of course, you need to download working code, or the SBC might need an EEPROM removal and re-program.

[BigEd]

I've been wondering about using an EEPROM that's too big, so one half can be known-working code while the other half is the new code-under-test. With suitable decoding logic and a switch (or button) one could choose whether to boot from known-working or code-under-test, and that would reduce the risk of any update or experiment.

[floobydust]

BigEd wrote:

I've been wondering about using an EEPROM that's too big, so one half can be known-working code while the other half is the new code-under-test. With suitable decoding logic and a switch (or button) one could choose whether to boot from known-working or code-under-test, and that would reduce the risk of any update or experiment.

I've been looking at the same... my thoughts are to use a port line (in my case, from the SC28L92) and connect that to an upper address line on the EEPROM. The code to switch the line should be copied from EEPROM to RAM first, then executed and have a know entry point back into the remapped EEPROM.

Adding a hardware jumper to the design would make it an easy cold start switch. Then again, you could also add a 4-position DIP switch and gain access to a larger device.

One small detail I fell into.... when I built up a 3.3V prototype, I switched to the AT28BV256 EEPROM. By default, this device requires an unlock code for insitu programming, where the AT28C256 device does not. I had to modify my EEPROM write routine to include those device writes to unlock it. Otherwise, there are no errors on compares... but when completed, nothing was actually written and the original contents remain.

[BigEd]

I like the soft-lock feature! But yes, you do have to adapt to it...

[floobydust]

Yes, a nice feature. You can also soft lock the earlier EEPROMs as well. My Monitor code has a routine I copy to Page Zero and execute. It writes a single byte to the EEPROM and compares it (outside of the write loop) as well. I didn't implement the page write mode, as that would consume more ROM space and really wouldn't make that much of a difference for writing larger images... quicker yes, but still....

Here's the routine that writes a byte to the AT28BV256. SRCL and TGTL are indirect page zero addresses. There also those locations plus one more for the high byte of the address:

Code: Select all

;Byte write code for EEPROM.
; Note: AT28BV256 requires an unlock sequence for all write operations.
;  This is different from earlier Atmel EEPROMs (i.e., AT28C256). The
;  sequence must be sent first to unlock the device, then data can be
;  sent for programming. Note that byte writes can be 1 to 64 bytes.
;  The EEPROM is defined in constants for the Offset of the EEPROM in
;  the hardware memory map.
;
BYTE_WRS        SEI                     ;Disable interrupts
;
                LDA     #$AA            ;Get code $AA
                STA     EEPROM+$5555    ;Send to EEPROM
                LDA     #$55            ;Get code $55
                STA     EEPROM+$2AAA    ;Send to EEPROM
                LDA     #$A0            ;Get code $A0
                STA     EEPROM+$5555    ;Send to EEPROM
;
                LDA     (SRCL)          ;Get source byte
                STA     (TGTL)          ;Write to target byte
                LDA     (TGTL)          ;Read target byte (EEPROM)
                AND     #%01000000      ;Mask off bit 6 - toggle bit
BYTE_WLP        STA     TEMP3           ;Store in Temp location
                LDA     (TGTL)          ;Read target byte again (EEPROM)
                AND     #%01000000      ;Mask off bit 6 - toggle bit
                CMP     TEMP3           ;Compare to last read (toggles if write mode)
                BNE     BYTE_WLP        ;Branch back if not done
                CLI                     ;Re-enable interrupts
BYTE_WRE        RTS                     ;Return to caller
;