$30000 $80 $AA EFILL --> ok
... $30000 $80 EE DUMP -->
0003.0000: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.0020: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.0030: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.0040: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.0050: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.0060: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.0070: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
... $12345678 $30000 E! --> ok
... $30000 $20 EE DUMP -->
0003.0000: 78 56 34 12 AA AA AA AA AA AA AA AA AA AA AA AA xV4.............
0003.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
...
Now, we're just a stone's throw away from reaching the 256KB limit:
$3FF00 $80 $AA EFILL --> ok
... $3FF00 $80 EE DUMP -->
0003.FF00: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.FF10: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.FF20: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.FF30: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.FF40: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.FF50: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.FF60: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0003.FF70: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
... $12345678 $3FF00 E! --> ok
... $3FF00 $20 EE DUMP -->
0003.FF00: 78 56 34 12 AA AA AA AA AA AA AA AA AA AA AA AA xV4.............
0003.FF10: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
...
I decided to plug in the other 256KB EEPROM, resulting in a total of 512KB on the I2C bus.
Here, we breached the 256KB boundary:
... $40000 $80 $AA EFILL --> ok
... $40000 $80 EE DUMP -->
0004.0000: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0004.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0004.0020: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0004.0030: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0004.0040: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0004.0050: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0004.0060: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0004.0070: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
... $12345678 $40000 E! --> ok
... $40000 $20 EE DUMP -->
0004.0000: 78 56 34 12 AA AA AA AA AA AA AA AA AA AA AA AA xV4.............
0004.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
Then past 320KB:
... $50000 $80 $AA EFILL --> ok
... $50000 $80 EE DUMP -->
0005.0000: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0005.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0005.0020: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0005.0030: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0005.0040: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0005.0050: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0005.0060: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0005.0070: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
... $12345678 $50000 E! --> ok
... $50000 $20 EE DUMP -->
0005.0000: 78 56 34 12 AA AA AA AA AA AA AA AA AA AA AA AA xV4.............
0005.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
And beyond 384KB:
... $60000 $80 $AA EFILL --> ok
... $60000 $80 EE DUMP -->
0006.0000: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0006.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0006.0020: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0006.0030: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0006.0040: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0006.0050: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0006.0060: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0006.0070: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
... $12345678 $60000 E! --> ok
... $60000 $20 EE DUMP -->
0006.0000: 78 56 34 12 AA AA AA AA AA AA AA AA AA AA AA AA xV4.............
0006.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
Then beyond 448KB:
... $70000 $80 $AA EFILL --> ok
... $70000 $80 EE DUMP -->
0007.0000: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.0020: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.0030: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.0040: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.0050: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.0060: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.0070: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
... $12345678 $70000 E! --> ok
... $70000 $20 EE DUMP -->
0007.0000: 78 56 34 12 AA AA AA AA AA AA AA AA AA AA AA AA xV4.............
0007.0010: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
And right up to the doorstep of 512KB:
... $7FF00 $80 $AA EFILL --> ok
... $7FF00 $80 EE DUMP -->
0007.FF00: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.FF10: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.FF20: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.FF30: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.FF40: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.FF50: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.FF60: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................
0007.FF70: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
... $12345678 $7FF00 E! --> ok
... $7FF00 $20 EE DUMP -->
0007.FF00: 78 56 34 12 AA AA AA AA AA AA AA AA AA AA AA AA xV4.............
0007.FF10: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ................ ok
...
Obviously, Peter's EEPROM access algorithms are working quite well
Obviously, Peter's EEPROM access algorithms are working quite well
Yes, I'll have to check out Peter's code. I didn't write Catalina's I2C code, so I have no attachment to it. If Peter's code is better and I can adopt it, I will happily do so - it might save me a lot of work
However, the problem could be speed related. Catalina's EEPROM loader is written in PASM. If Peter's code is written in Forth and your EEPROM circuitry is a bit marginal, it may be just enough slower to work.
BTW - Catalina's EEPROM loader is 100khz by default, but can be wound up to 400Khz by defining the HI_SPEED_SPI symbol (the same symbol is used for both SPI and I2C). You haven't defined that symbol by any chance?
Obviously, Peter's EEPROM access algorithms are working quite well
Yes, I'll have to check out Peter's code. I didn't write Catalina's I2C code, so I have no attachment to it. If Peter's code is better and I can adopt it, I will happily do so - it might save me a lot of work
However, the problem could be speed related. Catalina's EEPROM loader is written in PASM. If Peter's code is written in Forth and your EEPROM circuitry is a bit marginal, it may be just enough slower to work.
BTW - Catalina's EEPROM loader is 100khz by default, but can be wound up to 400Khz by defining the HI_SPEED_SPI symbol (the same symbol is used for both SPI and I2C). You haven't defined that symbol by any chance?
While my SPI routines run at 4MHz, this is way too fast for I2C so the interface is entirely in high level code but the default speed is 400kHz while 100kHz though rarely ever used does run at that speed.
... 0 LAP I2C@ LAP .LAP --> 2,016 cycles = 25.200us ok
... I2C100 0 LAP I2C@ LAP .LAP --> 8,064 cycles = 100.800us ok
Take into consideration that there are 8 data bits and an acknowledge bit plus the routines entry/exit overhead and this is about right.
Your code may be putting out very uneven clocks, maybe a very short high time, and this is exacerbated by the weak pull-ups which we still haven't heard back about yet.
Initially Peter had me lower the bus speed to 100Khz. When that worked, I cranked it up to 400KHz. So all tests beyond the initial 64KB block ran at 400KHz. I want to replace the pull up resistors with 1K ohms and see if I can push the bus to 1MHz (assuming Peter's code will let me do so). But that won't happen tonight. Maybe tomorrow or later this week.
BTW - Catalina's EEPROM loader is 100khz by default, but can be wound up to 400Khz by defining the HI_SPEED_SPI symbol (the same symbol is used for both SPI and I2C). You haven't defined that symbol by any chance?
No, in fact I wasn't aware that symbol existed. For my XMM SRAM API driver, I'm running the SPI bus for the SRAMs at the maximum speed I can get from PASM, so this symbol doesn't even come into play in this case.
As I proceed with writing the code to get the Flash API functions to work with the EEPROM instead of the SPI Flash (assuming I even can), I will have to be mindful of having sufficient delays to keep the I2C bus speed within specified limits...
Well, I'm going to call it quits for tonight. This has been a good day now that I know both of my 256KB EEPROMs are working fine. Many thanks to Peter for his help.
Your code may be putting out very uneven clocks, maybe a very short high time, and this is exacerbated by the weak pull-ups which we still haven't heard back about yet.
Entirely possible
What would the speed have been for @Wingineer's first test (the one that failed). Would that have been 1Mhz?
I have the default EEPROM speed set to 1MHz and it measures as that but there is overhead in-between bytes so the sequential read speed is 21us/byte or around 47kB/s.
By disabling EESPEED I can manually set the EEPROM routines speed for this test:
... REVECTOR EESPEED NOOP
... I2C100 0 LAP I2C@ LAP .LAP --> 6,528 cycles = 81.600us ok
... I2C400 0 LAP I2C@ LAP .LAP --> 1,920 cycles = 24.000us ok
... I2CFAST 0 LAP I2C@ LAP .LAP --> 1,152 cycles = 14.400us ok
... 0 BUFFERS 2048 LAP ELOAD LAP .LAP --> 3,515,968 cycles = 43.949ms ok
... 43949 2048 / . --> 21 ok
Replacing the SDA and SCL surface mount resistors on the Project Board with much lower values would be ideal, but for now I just added some additional resistors in parallel. The effective pullup resistance for the SDA and SCL lines is now about 2K ohms each.
I wanted to start fresh before resuming the testing, so I reloaded Tachyon into the Project Board. I'm assuming at this point that the I2C speed defaulted back to 1MHz.
I started with the 32KB EEPROM block above the boot sector and had Tachyon fill the next 32KB with "11".
I then proceeded to each 64KB block and had Tachyon fill the entire block with values, starting with "22", then "33", then "44", and so on, until the entire 512KB was filled.
The writing looks pretty fast for an EEPROM. Seemed like just a few seconds to cover the entire 64KB block...
Since you're obviously bored and have nothing else to do, I have another idea
If you're going to rewrite the I2C functions, why not make them more generic instead of being tied to the EEPROM?
For example, maybe redo the plugin to support up to 4 I2C Master ports, just like your serial driver can support 4 UART ports?
Then, introduce functions like these:
i2c_speed(port,value) Value=0 (100K), Value=1 (400K), Value=2 (1MHz)
i2c_start(port) Issues a start command on this port
i2c_stop(port) Issues a stop command on this port
i2c_restart(port) Perform a restart command on this port
i2c_write(port,value) Sends a single byte using this port
i2c_read(port) Reads a single byte from this port
Where the Definition file contains the pin values of SDA and SCL for each port.
These functions could be used not only with an EEPROM, but also devices like current/voltage/power sensors, temperature sensors, real time clocks, light sensors, touch sensors, accelerometers, gps receivers, etc, etc.
And if you ever want to redo a plugin for SPI support, I promise I won't bring up functions like:
Since you're obviously bored and have nothing else to do, I have another idea
Hmmm. First, we have to get the existing code working on your EEPROM
Now that we can examine the contents of the EEPROM, can you try loading a program using Catalina and then (assuming it doesn't work) fetch the contents of the EEPROM using the HAM asset manager? Or dump it using Tachyon and post the text of the first 32kb?
First, just try any normal non-XMM program (<=32kb), loaded using "payload -e program.binary" (this uses the Propeller EEPROM programming code). Any one of Catalina's demo programs will do, so long as you know it works.
Then, try the same program, but loaded using "payload EEPROM program.binary" (this uses Catalina's EEPROM programming code).
@Wingineer19 - no secret "source" involved here, all my stuff is out there and freely available. One thing though is not to read the I2C spec too closely but to keep a broad view of it in mind. With EEPROMs and practically all i2c devices there is no need to float the clock line so just drive it high and low. The same goes for SDA, just drive it high and low when writing data, and the only time you need to float it is when you read data or an ack bit. Avoid narrow clock pulses though, especially at higher speeds, try to make them squarer.
@RossH - this guy's crazy! Don't listen to his suggestions. You will go mad!
@Wingineer19 - BTW - If you had put a quarter of your effort so far into Tachyon instead, you would be finished and working on the next version of your software, without the need for any kind of fancy memory expansion. Just saying. (dig dig )
First, just try any normal non-XMM program (<=32kb), loaded using "payload -e program.binary" (this uses the Propeller EEPROM programming code). Any one of Catalina's demo programs will do, so long as you know it works.
OK, this is a simple program that prints this out:
Printed Hello World 1 Times
Then it waits for 1 second, then prints:
Printed Hello World 2 Times
Then it waits for 1 second, then prints:
Printed Hello World 3 Times
and on and on in a continuous loop with the "Times" value incrementing after each pass...
The file generated by the Propeller Loader is called PropLoaded.eeprom
Then, try the same program, but loaded using "payload EEPROM program.binary" (this uses Catalina's EEPROM programming code).
And the file generated by the Catalina EEPROM Loader is called CatLoaded.eeprom
On Windows I used this command:
c:\loader> fc /b proploaded.eeprom catloaded.eeprom
I will look at the differences, but did the program work when loaded using Catalina's loader?
Ok - cancel that. I have just loaded them both here, and they both work. The difference is just some additional zeroes padded at the end of the program, because of the way the loaders works. So we know Catalina can read/write the first 32kb of your EEPROM.
So, the next step is to do the same thing but compile it as a SMALL program (so it will use the next 32kb) then load it - e.g:
I enabled the CACHE_4K option before compiling, then did Download To XMM And Interact to verify the program still works. It did. Hopefully the cache enabling won't cause you any heartburn.
I then added the EEPROM option during compiling, uploaded the code to my board using the Catalina EEPROM loader, then downloaded 64KB of the EEPROM using the HAM.
I then added the EEPROM option during compiling, uploaded the code to my board using the Catalina EEPROM loader, then downloaded 64KB of the EEPROM using the HAM.
See attached.
Yes, using the cache is fine.
But did it work or didn't it when you used the -C EEPROM option?
Also, can you post your actual SMALL program binary? Catalina does some juggling about of segments when it puts things in EEPROM, so I need to see the original binary as well to make sure it got it right.
But did it work or didn't it when you used the -C EEPROM option?
I just tried it. Interestingly enough, it does work!
Also, can you post your actual SMALL program binary? Catalina does some juggling about of segments when it puts things in EEPROM, so I need to see the original binary as well to make sure it got it right.
I just tried it. Interestingly enough, it does work!
Ok - good. So this program works compiled as SMALL, but yours doesn't. Seems to be that perhaps size does matter after all!
So, let's try loading your program (compiled with -C SMALL and -C EEPROM and -C CACHED_4K) and then can you send me the entire EEPROM, plus your program binary. It would be good if you could use tachyon to zero the EEPROM (or set it to FF) before hand. But it is not essential.
I'm beginning to think that somewhere buried in Catalina's loader code is still a an EEPROM size limit, even though I can't seem to find it. The odd thing is that (if I recall correctly) the last time we tried it the load failed at 64Kb, not 128kb. But my loader is known to work up to 128kb
The EEPROM loader appears to be working with my latest version of the MenuTest program!
And last time we tried this, it didn't? Something is odd here.
The code looks like it's over 70KB in size, which sounds right.
I'm going to thoroughly walk through this, make sure the EEPROM has been completely erased, that my compiler options are correctly set for XMM on this program, and that I didn't screw something up to cause me to misread the result.
If this checks out, then the previous failure could have been hardware related, specifically the pullup resistor issue that Peter pinpointed...
It may take an hour or so to walk through all of this.
somehow one has to admit that the new fangled 'interactive testing' @"Peter Jakacki" is talking about all the time might have merits.
And I go somehow in the opposite direction, fiddling along with my first byte code interpreter to emulate a IBM 360 to run MVS on a P2. Not sure why I am doing that to me.
Pivoting back to Catalina to check XMM settings, recompile, copy to EEPROM, and then test...
OK, verified XMM SMALL CACHED_4K settings, included EEPROM Loader, recompiled, uploaded to EEPROM and...
It just puts a bunch of garbage on the screen. If you hit a key the initial Main Menu appears, but then it locks up after that. No further response.
As a sanity check, I went back and had it Download To XMM RAM And Interact instead, and it worked fine. Every menu option works perfectly in this mode.
Things looked promising there for a moment, but I guess it was a false dawn...
EDIT: I've attached two files from Catalina:
MenuTestNoLoader.binary
No EEPROM loader option included (allows upload to XMM SRAM for testing). This program works fine.
MenuTestWithLoader.binary
Uploaded to EEPROM for autorun on bootup, and doesn't work. This is also the one I pulled from EEPROM using HAM.
Things looked promising there for a moment, but I guess it was a false dawn..
No, this is good progress. You are no longer getting a loader error message when you use the EEPROM loader. I couldn't understand that one, so maybe that one was hardware related.
While I am checking out the EEPROM dump you posted, can you do me a favor and try the load again, but this time pre-filling the EEPROM with 00 instead of FF?
No, this is good progress. You are no longer getting a loader error message when you use the EEPROM loader. I couldn't understand that one, so maybe that one was hardware related.
While I am checking out the EEPROM dump you posted, can you do me a favor and try the load again, but this time pre-filling the EEPROM with 00 instead of FF?
Sure, here we go:
-Memory locations $8000 to $3FFFF cleared to $00 -> Confirmed
-MenuTest XMM recompiled as SMALL, CACHED_4K, EEPROM Loader -> Done
-MenuTest program uploaded to EEPROM -> Done
-MenuTest program execution -> Not working. Garbage characters. No response
-MenuTest program pulled from EEPROM using HAM -> Done
MenuTest.binary and MenuTestHam.eeprom files attached.
It's very late here (or very early if you want to look at it that way), so I've got to call it quits for now.
Hopefully there's enough clues in these files to help nail down the problem.
I'll check the Forum postings later on this morning to see if you found something.
Comments
Here, we breached the 256KB boundary:
Then past 320KB:
And beyond 384KB:
Then beyond 448KB:
And right up to the doorstep of 512KB: Obviously, Peter's EEPROM access algorithms are working quite well
Yes, I'll have to check out Peter's code. I didn't write Catalina's I2C code, so I have no attachment to it. If Peter's code is better and I can adopt it, I will happily do so - it might save me a lot of work
However, the problem could be speed related. Catalina's EEPROM loader is written in PASM. If Peter's code is written in Forth and your EEPROM circuitry is a bit marginal, it may be just enough slower to work.
BTW - Catalina's EEPROM loader is 100khz by default, but can be wound up to 400Khz by defining the HI_SPEED_SPI symbol (the same symbol is used for both SPI and I2C). You haven't defined that symbol by any chance?
While my SPI routines run at 4MHz, this is way too fast for I2C so the interface is entirely in high level code but the default speed is 400kHz while 100kHz though rarely ever used does run at that speed. Take into consideration that there are 8 data bits and an acknowledge bit plus the routines entry/exit overhead and this is about right.
Your code may be putting out very uneven clocks, maybe a very short high time, and this is exacerbated by the weak pull-ups which we still haven't heard back about yet.
Initially Peter had me lower the bus speed to 100Khz. When that worked, I cranked it up to 400KHz. So all tests beyond the initial 64KB block ran at 400KHz. I want to replace the pull up resistors with 1K ohms and see if I can push the bus to 1MHz (assuming Peter's code will let me do so). But that won't happen tonight. Maybe tomorrow or later this week. No, in fact I wasn't aware that symbol existed. For my XMM SRAM API driver, I'm running the SPI bus for the SRAMs at the maximum speed I can get from PASM, so this symbol doesn't even come into play in this case.
As I proceed with writing the code to get the Flash API functions to work with the EEPROM instead of the SPI Flash (assuming I even can), I will have to be mindful of having sufficient delays to keep the I2C bus speed within specified limits...
Well, I'm going to call it quits for tonight. This has been a good day now that I know both of my 256KB EEPROMs are working fine. Many thanks to Peter for his help.
By disabling EESPEED I can manually set the EEPROM routines speed for this test:
Replacing the SDA and SCL surface mount resistors on the Project Board with much lower values would be ideal, but for now I just added some additional resistors in parallel. The effective pullup resistance for the SDA and SCL lines is now about 2K ohms each.
I wanted to start fresh before resuming the testing, so I reloaded Tachyon into the Project Board. I'm assuming at this point that the I2C speed defaulted back to 1MHz.
I started with the 32KB EEPROM block above the boot sector and had Tachyon fill the next 32KB with "11".
I then proceeded to each 64KB block and had Tachyon fill the entire block with values, starting with "22", then "33", then "44", and so on, until the entire 512KB was filled.
The writing looks pretty fast for an EEPROM. Seemed like just a few seconds to cover the entire 64KB block...
Here's the result: So the resistor fix seems to work fine with the 1MHz bus speed.
Hopefully, you and @RossH can reach an agreement to use your I2C EEPROM algorithm within Catalina, including support for the the 1MHz bus speed.
Thanks again for your help. Tachyon is an excellent diagnostic tool, no doubt one of many functions it can provide!
Since you're obviously bored and have nothing else to do, I have another idea
If you're going to rewrite the I2C functions, why not make them more generic instead of being tied to the EEPROM?
For example, maybe redo the plugin to support up to 4 I2C Master ports, just like your serial driver can support 4 UART ports?
Then, introduce functions like these:
Where the Definition file contains the pin values of SDA and SCL for each port.
These functions could be used not only with an EEPROM, but also devices like current/voltage/power sensors, temperature sensors, real time clocks, light sensors, touch sensors, accelerometers, gps receivers, etc, etc.
And if you ever want to redo a plugin for SPI support, I promise I won't bring up functions like:
Where the Definition file contains the pin values for CS, CLK, and Data pins (depending upon standard, dual, or quad mode) for each port.
At least I won't bring them up just yet
Hmmm. First, we have to get the existing code working on your EEPROM
Now that we can examine the contents of the EEPROM, can you try loading a program using Catalina and then (assuming it doesn't work) fetch the contents of the EEPROM using the HAM asset manager? Or dump it using Tachyon and post the text of the first 32kb?
First, just try any normal non-XMM program (<=32kb), loaded using "payload -e program.binary" (this uses the Propeller EEPROM programming code). Any one of Catalina's demo programs will do, so long as you know it works.
Then, try the same program, but loaded using "payload EEPROM program.binary" (this uses Catalina's EEPROM programming code).
Then we'll move on from here.
Ross.
`
@RossH - this guy's crazy! Don't listen to his suggestions. You will go mad!
@Wingineer19 - BTW - If you had put a quarter of your effort so far into Tachyon instead, you would be finished and working on the next version of your software, without the need for any kind of fancy memory expansion. Just saying. (dig dig )
OK, this is a simple program that prints this out:
Printed Hello World 1 Times
Then it waits for 1 second, then prints:
Printed Hello World 2 Times
Then it waits for 1 second, then prints:
Printed Hello World 3 Times
and on and on in a continuous loop with the "Times" value incrementing after each pass...
The file generated by the Propeller Loader is called PropLoaded.eeprom
And the file generated by the Catalina EEPROM Loader is called CatLoaded.eeprom
On Windows I used this command:
c:\loader> fc /b proploaded.eeprom catloaded.eeprom
With a reply of:
Comparing files PropLoaded.eeprom and CATLOADED.EEPROM
00005E8C: FF 00
00005E8D: FF 00
00005E8E: F9 00
00005E8F: FF 00
00005E90: FF 00
00005E91: FF 00
00005E92: F9 00
00005E93: FF 00
So there are some differences. Hope it helps...
I will look at the differences, but did the program work when loaded using Catalina's loader?
Ok - cancel that. I have just loaded them both here, and they both work. The difference is just some additional zeroes padded at the end of the program, because of the way the loaders works. So we know Catalina can read/write the first 32kb of your EEPROM.
So, the next step is to do the same thing but compile it as a SMALL program (so it will use the next 32kb) then load it - e.g:
It may be too late! I accidentally looked at some Forth code, so my sanity is already questionable (dig dig )
+1
BTW, if insanity gets the job done, then how insane is that!?
"There is only one difference between a madman and me. The madman thinks he is sane. I know I am mad." - Salvador Dali
I enabled the CACHE_4K option before compiling, then did Download To XMM And Interact to verify the program still works. It did. Hopefully the cache enabling won't cause you any heartburn.
I then added the EEPROM option during compiling, uploaded the code to my board using the Catalina EEPROM loader, then downloaded 64KB of the EEPROM using the HAM.
See attached.
Yes, using the cache is fine.
But did it work or didn't it when you used the -C EEPROM option?
Also, can you post your actual SMALL program binary? Catalina does some juggling about of segments when it puts things in EEPROM, so I need to see the original binary as well to make sure it got it right.
Sure. See the Hello.binary attached.
Ok - good. So this program works compiled as SMALL, but yours doesn't. Seems to be that perhaps size does matter after all!
So, let's try loading your program (compiled with -C SMALL and -C EEPROM and -C CACHED_4K) and then can you send me the entire EEPROM, plus your program binary. It would be good if you could use tachyon to zero the EEPROM (or set it to FF) before hand. But it is not essential.
I'm beginning to think that somewhere buried in Catalina's loader code is still a an EEPROM size limit, even though I can't seem to find it. The odd thing is that (if I recall correctly) the last time we tried it the load failed at 64Kb, not 128kb. But my loader is known to work up to 128kb
I'm seeing some interesting stuff here.
The EEPROM loader appears to be working with my latest version of the MenuTest program!
And last time we tried this, it didn't? Something is odd here.
The code looks like it's over 70KB in size, which sounds right.
I'm going to thoroughly walk through this, make sure the EEPROM has been completely erased, that my compiler options are correctly set for XMM on this program, and that I didn't screw something up to cause me to misread the result.
If this checks out, then the previous failure could have been hardware related, specifically the pullup resistor issue that Peter pinpointed...
It may take an hour or so to walk through all of this.
Stand by...
Use Tachyon to fill the entire EEPROM with FF first.
Doing it now, along with a complete 256KB memory dump to verify
Pivoting back to Catalina to check XMM settings, recompile, copy to EEPROM, and then test...
somehow one has to admit that the new fangled 'interactive testing' @"Peter Jakacki" is talking about all the time might have merits.
And I go somehow in the opposite direction, fiddling along with my first byte code interpreter to emulate a IBM 360 to run MVS on a P2. Not sure why I am doing that to me.
Enjoy!
Mike
It just puts a bunch of garbage on the screen. If you hit a key the initial Main Menu appears, but then it locks up after that. No further response.
As a sanity check, I went back and had it Download To XMM RAM And Interact instead, and it worked fine. Every menu option works perfectly in this mode.
Things looked promising there for a moment, but I guess it was a false dawn...
EDIT: I've attached two files from Catalina:
MenuTestNoLoader.binary
No EEPROM loader option included (allows upload to XMM SRAM for testing). This program works fine.
MenuTestWithLoader.binary
Uploaded to EEPROM for autorun on bootup, and doesn't work. This is also the one I pulled from EEPROM using HAM.
Sure, here we go:
-Memory locations $8000 to $3FFFF cleared to $00 -> Confirmed
-MenuTest XMM recompiled as SMALL, CACHED_4K, EEPROM Loader -> Done
-MenuTest program uploaded to EEPROM -> Done
-MenuTest program execution -> Not working. Garbage characters. No response
-MenuTest program pulled from EEPROM using HAM -> Done
MenuTest.binary and MenuTestHam.eeprom files attached.
It's very late here (or very early if you want to look at it that way), so I've got to call it quits for now.
Hopefully there's enough clues in these files to help nail down the problem.
I'll check the Forum postings later on this morning to see if you found something.