Catalina EEPROM Loader Issues And Resolution
Wingineer19
Posts: 279
in Propeller 1
@RossH,
I decided to start a new thread on this topic instead of cluttering up the others we've been using.
Although the existing Catalina EEPROM loader does support up to 128KB EEPROMs, I'm hoping you'll give some thought to updating and modernizing its capability to support up to a full 512KB EEPROM map, just in case some crazy American comes along and writes code requiring that much space (slowly raising my hand
)
I guess the good news (at least for now) is that you won't have to consider going beyond the 512KB limit because the existing EEPROM device architecture only supports that much on a single I2C bus.
Anyway, for my testing and debugging I'm using two Propeller 1 Platforms: (1) A USB Project Board; and (2) A FLiP Module.
Here's a picture of the USB Project Board, which I modified by removing the existing 64KB EEPROM and replacing it with a 256KB one. (I've also added an additional 256KB EEPROM after this picture was taken for a final total of 512KB). Notice also the two SPI SRAM chips which operate in Quad Mode and execute my C code in XMM Memory:
However, this board is mainly used for software development and isn't meant to be deployed in the field. Because of this fact, I would like to focus the attention of this thread upon the FLiP module instead.
As we all know, the existing FLiP module comes with a 64KB EEPROM installed. For most users this appears to be a suitable accommodation, but for my application it's insufficient due to the fact my finished C code will likely fall between 128KB and 256KB in size.
My solution was to develop a Memory Board which the FLiP module will plug in to. The entire FLiP/Memory assembly would then plug into a socket on my main board.
Here's a side by side view of the Memory Board and the FLiP:
This Memory Board contains additional EEPROMs which extends the full EEPROM mapping on the I2C bus to 512KB. It also contains two SPI SRAMs, each operating in Quad Mode, to allow the FLiP to execute code in XMM Memory.
The upper three chips on the Memory Board are: one 64KB EEPROM, one 128KB EEPROM, and one 256KB EEPROM. The two lower chips are SPI SRAMs. There is a bypass capacitor adjacent to each of these five chips, and two pullup resistors for the I2C bus (SDA and SCL), and two pullup resistors for the SPI bus (CS and CLK). The Memory Board is powered from the 3.3V output of the FLiP module.
And here's the test arrangement with the FLiP plugged in to the Memory Board but not yet installed on the main board:
In my next post, I'll describe the overall EEPROM mapping arrangement, the problem I encountered with the Catalina EEPROM loader while attempting to store an XMM program while using it, and how I worked around it.
BTW, the SPI SRAM arrangement executes XMM code perfectly, so this portion of the Memory Board is not a subject of this thread.
I decided to start a new thread on this topic instead of cluttering up the others we've been using.
Although the existing Catalina EEPROM loader does support up to 128KB EEPROMs, I'm hoping you'll give some thought to updating and modernizing its capability to support up to a full 512KB EEPROM map, just in case some crazy American comes along and writes code requiring that much space (slowly raising my hand
)I guess the good news (at least for now) is that you won't have to consider going beyond the 512KB limit because the existing EEPROM device architecture only supports that much on a single I2C bus.
Anyway, for my testing and debugging I'm using two Propeller 1 Platforms: (1) A USB Project Board; and (2) A FLiP Module.
Here's a picture of the USB Project Board, which I modified by removing the existing 64KB EEPROM and replacing it with a 256KB one. (I've also added an additional 256KB EEPROM after this picture was taken for a final total of 512KB). Notice also the two SPI SRAM chips which operate in Quad Mode and execute my C code in XMM Memory:
However, this board is mainly used for software development and isn't meant to be deployed in the field. Because of this fact, I would like to focus the attention of this thread upon the FLiP module instead.
As we all know, the existing FLiP module comes with a 64KB EEPROM installed. For most users this appears to be a suitable accommodation, but for my application it's insufficient due to the fact my finished C code will likely fall between 128KB and 256KB in size.
My solution was to develop a Memory Board which the FLiP module will plug in to. The entire FLiP/Memory assembly would then plug into a socket on my main board.
Here's a side by side view of the Memory Board and the FLiP:
This Memory Board contains additional EEPROMs which extends the full EEPROM mapping on the I2C bus to 512KB. It also contains two SPI SRAMs, each operating in Quad Mode, to allow the FLiP to execute code in XMM Memory.
The upper three chips on the Memory Board are: one 64KB EEPROM, one 128KB EEPROM, and one 256KB EEPROM. The two lower chips are SPI SRAMs. There is a bypass capacitor adjacent to each of these five chips, and two pullup resistors for the I2C bus (SDA and SCL), and two pullup resistors for the SPI bus (CS and CLK). The Memory Board is powered from the 3.3V output of the FLiP module.
And here's the test arrangement with the FLiP plugged in to the Memory Board but not yet installed on the main board:
In my next post, I'll describe the overall EEPROM mapping arrangement, the problem I encountered with the Catalina EEPROM loader while attempting to store an XMM program while using it, and how I worked around it.
BTW, the SPI SRAM arrangement executes XMM code perfectly, so this portion of the Memory Board is not a subject of this thread.
Comments
Ok, with the hardware description of the FLiP and Memory Board arrangement done, along with the "pretty pictures", let's move on to the actual physical mapping of the EEPROMs on the I2C bus:
After compiling the latest edition of the MenuTest.binary program (96KB) and attempting to upload it to the FLiP/Memory contraption, the Catalina EEPROM Loader failed with the following LRC error:
Apparently the Loader couldn't make the transition from the 64KB FLiP EEPROM memory to the 64KB EEPROM on the Memory Board.
I then decided to load Tachyon into HubRam and use it's excellent EEPROM diagnostic capability to determine if it's even possible to write to and read from this 512KB EEPROM arrangement.
Here's what Tachyon reported:
This test verified that it was possible to write to the entire 512KB space, then successfully read back what was written. Whatever technique Tachyon uses to write/read to/from the EEPROM map works perfectly, and had no problem transitioning from one EEPROM to another during each sequence.
I then contacted @"Peter Jakacki" who confirmed that Tachyon uses the following sequence to write to the EEPROM memory:
After this, I concluded that the problem Catalina encountered was not hardware related, but rather the technique the Loader itself uses to write to memory.
I then wrote my own EEPROM Loader to verify that it could write/read to/from the full 512KB EEPROM map, and it did.
But instead of writing 128 byte pages like Tachyon, I decided to start small using 16 byte pages. Eventually I'll try larger page sizes.
Starting at location $00000 the Loader would write $00, then $01 to the next location, then $02 to the next, etc, etc, until a full 255 bytes had been written representing the ASCII character set. The sequence would then repeat until the full 512KB had been written.
Here is a snippet of the Tachyon dump which verified my Loader was working:
$0000 $80000 EE DUMP --> 0000.0000: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ................ 0000.0010: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................ 0000.0020: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 0000.0030: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 0123456789:;<=>? 0000.0040: 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F @ABCDEFGHIJKLMNO 0000.0050: 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F PQRSTUVWXYZ[\]^_ 0000.0060: 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F `abcdefghijklmno 0000.0070: 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F pqrstuvwxyz{|}~. 0000.0080: 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F ................ 0000.0090: 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F ................ 0000.00A0: A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF ................ 0000.00B0: B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF ................ 0000.00C0: C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF ................ 0000.00D0: D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF ................ 0000.00E0: E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF ................ 0000.00F0: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ 0007.0000: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ................ 0007.0010: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................ 0007.0020: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 0007.0030: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 0123456789:;<=>? 0007.0040: 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F @ABCDEFGHIJKLMNO 0007.0050: 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F PQRSTUVWXYZ[\]^_ 0007.0060: 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F `abcdefghijklmno 0007.0070: 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F pqrstuvwxyz{|}~. 0007.0080: 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F ................ 0007.0090: 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F ................ 0007.00A0: A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF ................ 0007.00B0: B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF ................ 0007.00C0: C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF ................ 0007.00D0: D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF ................ 0007.00E0: E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF ................ 0007.00F0: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................The Loader consists of two C programs: (1) PropLoad; and (2) UpLoad.
The PropLoad program executes within HubRam of the FLiP itself and was written using Catalina C.
The UpLoad is a Windows 10 Console program and was written using OpenWatcom.
The UpLoad program takes the EEPROM binary file you specify, then invokes your Payload program to install the PropLoad program within HubRam, then commences to send the binary file over to the Prop to be written into EEPROM.
Right now the Loader only writes a page at a time to EEPROM, but doesn't read it back to verify it was successful. It does look for an ACK response after each byte is sent to EEPROM, and will send a "TimeOut" error to the Win10 UpLoad program if a NACK is received, thus aborting the process. As long as it receives an ACK after each byte is sent to the EEPROM, the Loader will continue until the entire binary file has been written.
It's slow compared to Tachyon and the Catalina Loaders, primarily due to how the communication between the Win10 and FLiP occurs. I'm using only ASCII printable characters instead of binary, so the Prop has to take these characters and convert them back into binary before writing to memory.
I typically don't comment my code because I feel if I had to suffer while writing it, then the next person trying to decipher it should have to suffer too
But I'll be happy to walk you through what the Loader is doing if you desire in a future post.
Hopefully there's something here you will find useful to help upgrade the Catalina Loader to support 512KB EEPROM mapping. If you can tolerate the speed penalty, it's possible to write the whole thing in Catalina C and avoid having to use PASM and/or SPIN.
In the meantime, I'm back in business with a functioning Loader so I can resume work on the MenuTest program.