*UPDATE* Bootstrap EEPROM

JSWrightOC

This is an idea I just thought of, for a project I am working on.

I will be building this system using OEM Basic Stamp parts, and I have all of the parts on hand to test it - I just wanted to see if anyone had tried this before or not.

Part of the requirement for this project is to have a removable "memory card" (really a small PCB with an edge connector and some EEPROM chips on it) that will contain the I2C serial EEPROM for the Basic Stamp, as well as an SPI EEPROM that will contain other information that the program uses. I want to account for contingencies such as a non-present memory card, as well as a couple of other features, and was wondering if I could connect two I2C EEPROMs to the SDA and SCL connections on the interpreter chip, one on the memory card and one soldered directly to the main board, and enable only one at a time. To switch between the two, the bootstrap EEPROM program would issue a signal to a hardware latch that would simutaneously disable the bootstrap EEPROM, enable the normal program EEPROM, and generate a reset pulse to reset the interpreter chip, without resetting the state of the latch. Execution will then switch over to the main program EEPROM (which is on the memory card) and the system would run off of it until power is disconnected and reapplied. The bootstrap program would do some simple sanity checks, like if a memory card is present or not, and also compare information like the serial numbers and version information encoded in the EEPROMs. If it doesn't like something, then it can halt operation and warn the user.

Thoughts?

Post Edited (JSWrightOC) : 9/25/2007 6:13:52 PM GMT

allanlane5

Usually, I don't like the operation of my processor to be dependent on somebody plugging in the right device. Putting the 'main execution token' eeprom on a removable card is not something I would do. That would be like running your PC off of a USB-bus connected hard drive -- convenient in concept, but a little risky in actual operation.

I assume you want to implement this architecture in order to be able to 'upgrade' the operating code of the BS2 simply by plugging in an 'upgraded' card. So be it.

It's hard in this architecture to "account for a missing memory card", since without a memory card you basically HAVE no operating system. And I believe it's difficult in the BS2 architecture to support "swapping out the program eeprom", because that's not really something envisioned in any of the BS2's "operational modes" (or an I2C eeprom either)

Having said all that, I suppose by using a hardware latch to enable one eeprom or another, it might be possible to build a gizmo which would use a 'reset' pulse to change which 'eeprom' is being run, AND reset the processor to use the 'new' eeprom. Since this was never envisioned by the original architecture, there might be several hidden 'gotcha's' that would make it very difficult.

JSWrightOC

I admit it is definitely a hardware hack. It is quite clear that Parallax never had this kind of usage in mind when they released the OEM components for sale to the public. However, to answer your questions...

The memory card is something that would get installed "at the factory" and not messed with until a newer firmware version was released. At this point cards containing the new firmware would be distributed and installed in the field. Personally I don't think this is much different from socketing the EEPROM chip and having an engineer swap it out (this was common practice with UV EEPROMs), other than the fact that there is less potential for harm to the component when it is in a pluggable card form factor, versus a delicate (and easily mis-inserted) DIP chip. To use your PC analogy, let's assume this is an embedded computer platform (such as a kiosk of some kind). The manufacturer wants all of the field technicians to upgrade the system, and they have distributed hard drives with the software already installed and ready to go on them. This makes it easy for the field techs, as it is a fairly trivial matter to replace a hard drive (especially if it is SATA). Compare this to having the techs physically remove the platters from the hard drive, and then install new platters encoded with the upgraded software - you are achiving the same effect, but by changing out the entire hard drive you are making the operation much simpler and less prone to failure.

As for the "accounting for a missing memory card" that would be one of the purposes of the bootstrap EEPROM. First would be to perform a sanity check on the hardware, and authenticating the memory card to ensure it has compatible firmware, before handing control over to it. This is similar in theory to the way a computer BIOS works. The BIOS initializes some vital hardware - checking system RAM, verifying the presence of required peripherals (video card, keyboard, etc.) - and then searches for bootable devices, before handing control over to the bootloader for the operating system.

The I2C EEPROM used by the BS2sx is a 128kbit part made by Microchip. The datasheet for this device says there are 3 address pins, to allow up to 8 devices to be connected in a segmented memory array. Because the Parallax documentation says to ground these three pins, I think we should be able to safely assume that the interpreter chip will always look for a device at address 0, and consequently never see any devices with addresses of 1-7. The hardware latch would merely change the state of one of the address pins, so now one of the two EEPROMs is at address 0, while the other is at 1 (or 2, or 4), and then reset the interpreter chip. Resetting the interpreter after making this swap would allow it to initialize properly, like nothing had ever happened. It's at least worth testing. I just wasn't sure if anyone had tried it or not.

Chris Savage

If your memory card design wasn’t already done you could do something like I used to do back in the Commodore days (borrowed it from them). The expansion card would short a pulled-up line low to switch some logic selecting the external card as the memory device. As for how this could be done, it could be a simple inverter. One end goes to the memory card and the other to the ‘bootstrap’ EEPROM. By default the internal ‘bootstrap’ EEPROM would run. If a card was inserted it would affect A0 on both cards effectively switching the ‘bootstrap’ EEPROM to a higher slave address and the memory card to the default one. I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

allanlane5

Your solution might be MUCH more complicated than saying something like "The system will not run without a card installed", and leave it at that.

But I agree, it might be a cool hack, if you can get it to work.

One last thing -- there's a chicken and egg situation here you need to work around. The processor can't 'reset itself' if you've swapped out the eeprom with the running code that tells it how to 'reset itself'. So, the 'hardware latch' needs to be more complicated than a simple latch, if it is ALSO going to generate the 'reset' signal some time AFTER it changes the eeprom address.

Another way to work around this would be to use a simple latch IC, have the BS2 send a signal to the latch to indicate which eeprom should be enabled on reset, then the BS2 send itself AND the latch the 'reset' signal. The latch gets the reset, and uses it to enable the desired eeprom. The hardware latch would thus need 'two' stages -- one to hold the 'current' eeprom address line, and one to hold the 'desired' address which will 'clock' across on 'reset'.

JSWrightOC

*UPDATE*

I made it work!

The modification was pretty simple, as I expected. I wired two I2C EEPROMs to the SDA and SCL pins of the interpreter chip, and then used a D flip-flop (though in practice any kind of hardware latch would have worked) with the Q and not-Q outputs each feeding one of the A0 pins of the two EEPROMs. A1 and A2 were tied to ground. In reality with some combinational logic you could index up to 8 EEPROMs this way, using A1 and A2. I connected the D input of the flip flop to a convenient pin on the Stamp interpreter, and then used another convenient pin to drive the clock input of the flip-flop. I used a resistor-capacitor network to reset the D flip-flop on power-up, so it always comes up in a known state. I could also have used a brown-out detector or reset pulse generator, which I will probably do in my final design. To generate the reset pulse for the interpreter, I used a very simple circuit that triggers an NPN transistor to pull RESET low briefly when the flip-flop changes states. This consisted of the transistor plus two capacitors and four diodes, wired in a dual edge-detecting circuit with recovery. Whenever the flip-flop changes states, a reset pulse is generated. By generating the reset pulse on the output change of the flip-flop, I can guarantee that any setup and hold times for the flip-flop are met because the reset pulse is not generated until all signals in the flip-flop ripple through to the output.

So, put this in your application notes!!

allanlane5

No fair! You went ANALOG on us! Using a transistor, capacitors, and diodes to make a time delay. Sneaky!

Seriously -- well done. That sounds like a very neat hack, right up there with the "reset a BS2 on external event signal to get fast interrupt response and low idle power" hack.

There might be some interest in this approach. People are always trying to find simple and inexpensive ways to update the firmware of the BS2 program without too much difficulty.

JSWrightOC

Well, sooner or later something analog will have to happen somewhere. Even circuits such as crystal oscillators and ceramic resonators are analog. I really didn't need a time delay, I just needed to trigger on the edge of a pulse, and a capacitor with a recovery diode driving a transistor does that nicely.