HOWTO change to a larger EEPROM on the BeMicroCV so that the P1V will boot from a saved binary.
LoopyByteloose
Posts: 12,537
Since I wrote this HOWTO, I am providing it at the top of a new thread.
We have an earlier thread discussing the possibility of doing this, but this one is focused on the actual procedure. It may also provide an example for reassignment of FPGA i/o to exploit the SDcard slot on the BeMicroCV and other features (the push-buttons and dip switches).
Good luck.
We have an earlier thread discussing the possibility of doing this, but this one is focused on the actual procedure. It may also provide an example for reassignment of FPGA i/o to exploit the SDcard slot on the BeMicroCV and other features (the push-buttons and dip switches).
Good luck.
Comments
You may be fine if you only use 64Kx8 or 32Kx8, but run into problems with larger. I have to spend some time researching before I am willing to offer advice on specific purchases.
I desire to get as large an EEPROM as I can that will work with any Propeller 1, not just the BeMicroCV. But there are special advantages of having a larger EEPROM available on an FPGA as code can be adapted to do new things.
Here's a pin assignment diagram that was posted on the P1 Verilog forum ~12 months ago.
I can't seem to find the original post or remember the author?
These may help with your experiments.
When I download the TXT file it has Unix style line endings so if you're downloading the file in Windows, you'll want to open it in Wordpad instead of Notepad.
For the replacement EEPROM, you can get a 24LC256 or equivalent. Larger-capacity EEPROMs (such as 24LC512 for 64KB) will also work -- the same rules apply as for the regular Prop: if the boot loader can use the same commands to get the first 32K out of the EEPROM, it's good enough. I'm not sure but I think the largest I2C EEPROM that Microchip makes available is 1MB; above that, you can only get SPI which won't work to boot the Propeller, no matter what size.
You will need a SOIC package EEPROM if you want to replace the on-board EEPROM neatly, but if you have a DIP EEPROM and don't want to spend $$$$$ to ship one little less-than-$3 chip to you, you can also hack it: TP7 and TP8 on the BeMicroCV are connected to the I2C bus (refer to the schematic to find out which is which); you can desolder the original EEPROM and dead-bug a DIP EEPROM to the two testpoints. The EEPROM only needs 3.3V on pin 8, I2C on pins 5 and 6 and GND on all the other pins.
Instead of reassigning pin P16 and P17 to io[29] and io[28] respectively in the .qsf file as Loopy suggests, I would probably take a different approach. In the old Github repo, I just added the following lines to the .qsf file to identify the EEPROM pins: I would also rename the header pins so they're not directly connected to io[28] and io[29] in the top module anymore. That way, it's possible to write some Verilog to assign the Propeller logic to the pins, e.g. depending on the DIP switches. Hopefully I'll find some time to do this in the next few days.
However, even though I replaced the EEPROM on my own BeMicroCV because I happened to have an EEPROM available on an old Propeller board that wasn't working anymore, I have to say I regret it. The reason is that it makes my board potentially incompatible with everyone else's. I think it would be a better idea to put some work into a "shield" type board with EEPROM (and Prop plug) functionality, and use the onboard EEPROM to store configuration information. As I mentioned elsewhere, I'm thinking of using the DIP switches to change the configuration without the need to reflash the FPGA, and I think it might be more interesting to eventually use an internal state machine for that, which can be changed with the pushbuttons (and feedback from the LEDs); in that case it would be necessary to store the configuration somewhere, and the EEPROM would be the only place to do that, since the FPGA can't change its own flash memory as far as I know.
===Jac
Yes, my .txt files are in Unix style due to my use of Linux. Actually written in gEdit.
The J1 and J4 diagram overlaying the board for the BeMicroCV is helpful. But I keep going back to the schematic just to be sure of what is going on. One needs to note pullup resistors on J2 and J4.
And I really do not know how to standardize the EEprom hack. Everyone is likely to want something a bit different. I am now considering a 2Mbit SMD EEprom as they seem available in single quantities from Digikey. The existing PNut Boot V0.10 will only load a 32kbyte binary regardless of the vast size, but I am considering a modified PNut Boot if I can get a Spin compiler to play along with larger binaries.
While this modification is being first done on my BeMicroCV due to it being low cost and less of loss if damaged, I am considering eventually doing the same on the BeMicroCVA9 as the tiny existing EEprom makes no sense to me.
Documenting all the alternative permutations in the same detail as I have provided for the BeMicroCV and this one option, could become burdensome.
+++++++
Yes, I could divert to BeMicro designated I2C pins and they seem to be wired with the appropriate pullups resistors in place. ( I need to recheck this.)
I actually may try that with the 8 pin DIP EEprom I have, while I am waiting for the arrival of the SMD devices. I hadn't considered the alternative, and just noticed the existing pullups while reading the BeMicroCV schematic yesterday.
In any event, it certain is possible to adapt the BeMicroCV to retain Spin binaries of the standard 32K in an EEprom. There just seems to be an array of solutions that offer different possibilities..
###################################
The BeMicroCV actually has two I2C buses complete with pullup resistors which are available to the user. Until now, I have presumed that there was just one.
One is dedicated to the on-board 24c01 EEprom which can be replaced with a larger device and still allow it to be used as if the smaller 24c01 was present if necessary.
And the second is on the PinHeader_B (J4). The ONLY to pins on that header with pullup resistors.
By looking at Page 16 and 17 of the BeMicroCV_A2 pdf, you can confirm the difference. They have different pull-up resistors assigned to them and different Altera i/o port identities.
++++++++++
Since the standard BeMicroCV will not be degraded for other uses by swapping the 24c01 for a larger EEprom, I intend to eventually do that and try to acquired the largest compatible I2c EEprom I can.
But, the fact that the PinHeader_B I2C includes the necessary pullups makes it very very easy to build a tiny daughter board for a conventional DIP EEprom. It seems I might as well try building that board and using that port while I wait for me SMD devices.
=========
The main point here is that the BeMicroCV and other FPGAs do indeed have lots of i/o pins that take some study to figure out what you can use and what you need to do to properly use them. (I just jumped in and thought I had to use the PIV_pin 28 and 29 to get a useful EEprom boot, simply no so.)
The best news is that the P1V-pin 29 that I damaged is completely unnecessary if I choose to use one or both of the other I2C channels with the P1V code.
That pin may be necessary for a BeMicro daughter board such as the BeScope, but not for the P1V.
Most definitely. When you look closely, you will see that there are two resistors labeled R71 and R72 next to TP7 (SDA) and TP8 (SCL), on the back side of the board near the EEPROM. Those are the pull-up resistors.
It's probably not too hard to change the P1V Verilog code so that it connects io[28] and io[29] to EEPROM_SCL and EEPROM_SDA during boot time, and to the J1 header once the boot loader is done. FPGA's are wonderfully flexible that way.
I would say the best thing to do is leave the hardware unmodified, and let the Verilog do all the tricks (or as many tricks as possible). For example, you can easily add a boot loader that checks for a large enough EEPROM (on EEPROM_SCL/EEPROM_SDA as well as P28/P29) and loads the next boot stage from wherever it can find one. That next boot stage can be on the SD card too. You don't even have to invent it, others have already done this (Jon McPhalen if I'm not mistaken). All you need to do is change the Verilog so that the right code is in the right place at the right time.
That said, I'm probably going to put some effort into designing a "shield" board for the BeMicroCV and CVA9 this weekend, and get it fabricated by OSHpark. As I mentioned before, I'm thinking it should have headers at the bottom that are compatible with at least the CVA2 and the CVA9, and headers on top to plug in anything that can be plugged in to a QuickStart. It will definitely have an EEPROM socket and definitely a header for a Prop Plug but I may even put an FTDI chip right on the board so you won't even need a Prop plug. I'm also thinking of adding a header that's pin-compatible with the Propeller chip so that it's theoretically possible to make a ribbon cable that you can plug into another Propeller circuit, so you can use the P1V for in-circuit debugging.
===Jac
The original scheme was clever, but crowded the 32 Propeller i/o on PinHeader_A. If I must divert the i/o in Verilog, this seems a much cleaner build.
Meanwhile, I have located 128Kx8 I2C EEproms that might replace the 24c01 EEprom that BeMicro provided, but am still looking for two or four times larger EEproms as they may one day allow the P1V to support huge Propeller SPIN binaries at boot.
(Okay, I know I am being greedy, but these EEproms are NOT available in 8 Pin DIP packages, only SOIC8. Added cost is minimal and the resoldering labor all the same.)
@jac_goudsmit
I know you have been pondering an actual shield for the BeMicroCV for quite some time. I look forward to seeing what you come up with, but wonder if you can recapture the expense of making one. It is simply hard for me to say.
So many people just want something completely different.
Just some observations...
A. ADC and DAC seem to always be wanted.
B. The possibility of plugging in modular Pololu's stepper motor controller and H-bridges would open new horizons that were barred to the Propeller 1 due to 32K Hubram limit.
C. A space for one of those tiny breadboard might be much appreciated.
D. Accommodation of added power should not be neglected. While the BeMicroCV can do some things with USB power only, more ambitious projects will demand far more than the 500ma that the USB supposedly provides. One might need 3-5amps, and the motor controllers might desire secondary power for the motors.
E. VGA, mouse, and keyboard are Propeller 1 classics, but the mouse and keyboard should have 5VDA at 500ma each provided. Even though a lot of devices claim to operate at less amps, they seem to have a surge of demand when starting.
F, A I2C EEprom solution for both 8-pin DIP and SMD SOIC8 devices, maybe more I2C expansion.
Personally, I dislike the idea of providing power for more than 3 amps in printed circuit form. The physical cross-section of wire for more amps than that point to round wires, not wider flat ones.
When you consider getting a 64pin experimental Propeller with SDcard slot, Dram, and all the other stuff (LEDs, button, dip switches) for only $50.00USD in a BeMicroCV -- it is an excellent value. But I see the BeMicroCV is currently on backorder.
Here it is typhoon season. When it is sunny, the UV is dangerously high. And when it is not, torrential rains keep us inside. So it is kinda like winter in the US.
===============
Looking into the actual boot time of a 32KB Spin binary at 400Khz, I get something around 0.644 seconds.
So if this EEprom hack is extended to a 128KB that is expected to boot and load, something like 2.5 seconds is going to be required to boot. Going larger by 2x or 4x gets even more dismal.
So it might be smarted to have the 32KB or 64KB EEprom merely contain a binary that would search and load from the SDcard that is about 10 times faster (maybe even more).
+++++++++++
I finally located 128KB EEproms that are appropriate and then started to think I should get even larger. That all seems rather silly now, so that may be as large as I am personally going to attempt to install.
And it seems the a 32KByte EEprom may actually be all that one really might need. But I have to import the SMD versions anyway, none in Taiwan of any size.
It seems that the retail outlets gave up keeping up with stocking new ICs inventories about the time that the world was changing from DIP to SMD.... way too much inventory that doesn't have much volume in the over-the-counter trade.
I can buy SMD capacitors, resistors, and connectors -- but actual logic seems nowhere to be found.
Have the CV sitting on shelf. Have compilied several builds but not delved into actual code and putting it all together in my pebble mind.
More of an RF kinda guy little slow in programming!
https://www.newark.com/samtec/mec6-140-02-l-d-ra1/connector-card-edge-recepticle/dp/85T5569
This is the connector for the 80 pin edge connector, available from several sources. That will open up 57 more i/o for general use.