I think you are running in a Problem with P2load's terminal.
I have sometimes the opposite effect, chars with spaces in between. As much as I praise Spin2Gui and Fastspin there is some issue with the terminal of P2load. I had no time to figure this out but I had some strange experiences the last week while fighting to integrate TAQOZ and Fastpin compiled stuff.
My current theory is that the terminal is effing up on some character combinations. I had a couple of times the situation that I needed to HEX out the data or the Terminal misbehaves.
Since my goal is somewhere else I just live with it and hex- out when problems arrive.
But maybe you are fighting windmills, your program is fine, the output of the Terminal f..es up sometimes.
I have not investigated this deep, but P2loads Terminal is - hmm - misbehaving sometimes.
It could be some problem with the loader, but it's more likely that some memory within the XMM Kernel itself is being overwritten somehow.
Here's some sample code that writes to XMM Memory via the Cache (which works fine):
XMM_WritePage andn outa,RamSel 'RamSel=Lo (SRAM Active)
call #SendWriteCmd 'Configure SRAM For Writing
:HubData rdbyte RamData,Hub_Addr 'HubRam -> RamData (This Is A Byte)
mov RamLoop,#02 'RamLoop=2 (Send 2 Nibbles To SRAM)
call #SendRamData 'RamData -> SRAM
add Hub_Addr,#01 'Hub_Addr=Hub_Addr + 1
add XMM_Addr,#01 'XMM_Addr=XMM_Addr + 1
djnz XMM_Len,#:HubData 'if(--XMM_Len > 0) goto HubData
or outa,RamSel 'RamSel=Hi (SRAM Inactive)
XMM_WritePage_ret ret 'Return
Notations:
XMM_Len: Number of Bytes to write to SRAM
Hub_Addr: Hub Address location from which the Bytes are to be fetched.
XMM_Addr: The SRAM location to which the Bytes are to be written.
The SendWriteCmd function is benign. It simply sends the SRAM Write Command ($02) with the address appended to it (for example, $0207ABCD) to the SRAM stating that it wants to write data to it at address $07ABCD.
The SendRamData function writes a Byte to this location (with the Byte sent as 2 Nibbles because this is a 4-bit data bus).
Now, here's the code to write to XMM Memory in Direct Mode (which doesn't work):
Notations:
XMM_Len: Number of Bytes to read from SRAM
XMM_Addr: The SRAM location from which the Bytes are to be fetched.
Hub_Addr: Hub Address location to which the Bytes are to be written
The SendReadCmd is just like the SendWriteCmd, except it uses a $03 (read) instead of the $02 (write) command prefix. It's followed by the address (for example, $0307ABCD) and sent to the SRAM stating that it wants to read data from this address.
The GetRamData function reads a Byte from this location (with the Byte reconstructed from two successive Nibble reads, again due to the 4-bit data bus)
Now, here's the Direct Read Function, which doesn't work:
With XMM_Len once again restricted to values of 1,2, or 4 in Direct Mode.
Notice how it uses the exact same two functions (SendReadCmd and GetRamData) that the Cached function uses.
Again, the HubRam isn't used, so the Byte(s) are to be written to a CogRam location specified by the Kernel:
XMM_Dst mov 0-0,RamData
With the 0-0 overwritten by the Kernel via the MOVD instruction thus pointing to the CogRam location.
There's nothing mysterious with the SendWriteCmd, SendRamData, SendReadCmd, and GetRamData functions, so I'm just wondering if the MOVS and MOVD process within the Kernel is somehow overwriting portions of the Kernel itself and trashing the screen...
..
But maybe you are fighting windmills, your program is fine, the output of the Terminal f..es up sometimes.
I have not investigated this deep, but P2loads Terminal is - hmm - misbehaving sometimes.
Yes, it is a good idea to have more than one terminal, for simple 'sanity checks'.
So something is definitely going on here but RamTest can't complete the TRIV confirmation as shown by the Screen trashing.
Likewise, if we look at the CMPX Screen:
It seems as if CMPX is attempting to write "Passed" but only the "asd" portion is shown mixed in with a lot of other garbage.
to me it looks like every second letter is missing
DEADBEEF - dEaDbEeF - EDEF
Well spotted. It is not 'trashing' in the classic sense, as there is no garbage appearing. It's a somewhat well behaved failure.
The effect is consistent with code being too fast for a serial reporting link - how does it change, if you change the BAUD rate ?
It could be some problem with the loader, but it's more likely that some memory within the XMM Kernel itself is being overwritten somehow.
Here's some sample code that writes to XMM Memory via the Cache (which works fine):
XMM_WritePage andn outa,RamSel 'RamSel=Lo (SRAM Active)
call #SendWriteCmd 'Configure SRAM For Writing
:HubData rdbyte RamData,Hub_Addr 'HubRam -> RamData (This Is A Byte)
mov RamLoop,#02 'RamLoop=2 (Send 2 Nibbles To SRAM)
call #SendRamData 'RamData -> SRAM
add Hub_Addr,#01 'Hub_Addr=Hub_Addr + 1
add XMM_Addr,#01 'XMM_Addr=XMM_Addr + 1
djnz XMM_Len,#:HubData 'if(--XMM_Len > 0) goto HubData
or outa,RamSel 'RamSel=Hi (SRAM Inactive)
XMM_WritePage_ret ret 'Return
Notations:
XMM_Len: Number of Bytes to write to SRAM
Hub_Addr: Hub Address location from which the Bytes are to be fetched.
XMM_Addr: The SRAM location to which the Bytes are to be written.
The SendWriteCmd function is benign. It simply sends the SRAM Write Command ($02) with the address appended to it (for example, $0207ABCD) to the SRAM stating that it wants to write data to it at address $07ABCD.
The SendRamData function writes a Byte to this location (with the Byte sent as 2 Nibbles because this is a 4-bit data bus).
Now, here's the code to write to XMM Memory in Direct Mode (which doesn't work):
Notations:
XMM_Len: Number of Bytes to read from SRAM
XMM_Addr: The SRAM location from which the Bytes are to be fetched.
Hub_Addr: Hub Address location to which the Bytes are to be written
The SendReadCmd is just like the SendWriteCmd, except it uses a $03 (read) instead of the $02 (write) command prefix. It's followed by the address (for example, $0307ABCD) and sent to the SRAM stating that it wants to read data from this address.
The GetRamData function reads a Byte from this location (with the Byte reconstructed from two successive Nibble reads, again due to the 4-bit data bus)
Now, here's the Direct Read Function, which doesn't work:
With XMM_Len once again restricted to values of 1,2, or 4 in Direct Mode.
Notice how it uses the exact same two functions (SendReadCmd and GetRamData) that the Cached function uses.
Again, the HubRam isn't used, so the Byte(s) are to be written to a CogRam location specified by the Kernel:
XMM_Dst mov 0-0,RamData
With the 0-0 overwritten by the Kernel via the MOVD instruction thus pointing to the CogRam location.
There's nothing mysterious with the SendWriteCmd, SendRamData, SendReadCmd, and GetRamData functions, so I'm just wondering if the MOVS and MOVD process within the Kernel is somehow overwriting portions of the Kernel itself and trashing the screen...
We don't see the code that uses XMM_Addr so I can't tell if it is truly relevant, but in the Cache version it is incremented by one for each time through the loop, while in the Direct version it is updated once prior to the call that transfers the data. For bytes XMM_Addr should update at the same rate, so do byte transfers work with both methods? What size transfers are used in the test that corrupts the display?
We don't see the code that uses XMM_Addr so I can't tell if it is truly relevant, but in the Cache version it is incremented by one for each time through the loop, while in the Direct version it is updated once prior to the call that transfers the data. For bytes XMM_Addr should update at the same rate, so do byte transfers work with both methods? What size transfers are used in the test that corrupts the display?
I've attached the latest XMM driver functions for review.
The XMM_Addr, Hub_Addr, and XMM_Len variables are provided to my functions by the Kernel and outside the control of my driver. If there was a way to capture this information it would be helpful for troubleshooting.
In Direct Mode the XMM_Len value is restricted to 1,2, or 4 bytes per function call. I know for instruction fetches this value is always 4, but I don't know what the most common value is for data transfers. That's a question @RossH can answer.
Since my Direct Mode functions don't mess with XMM_Len (aside from copying its value into the RamLoop variable -- then converting RamLoop into Nibbles), it doesn't really matter where in the function that XMM_Len is added to XMM_Addr. In the examples above it's added near the start of the function, but in my latest code it's added at the end of the function. It makes no difference as far as the test failure goes.
In Cached Mode the value of XMM_Len can be much greater than 4, likely hundreds (or maybe thousands) of Bytes, as requested by the Kernel. In this case my functions simply increment both Hub_Addr and XMM_Addr by one during each iteration through the loop. The final result is that both XMM_Addr and Hub_Addr have both been incremented by XMM_Len, similar to how the XMM_Addr value has been incremented by XMM_Len in the Direct Mode functions.
The Loader uses the Cached Mode functions to transfer the program to the propeller. In my latest code it transfers single bytes, so the Loader is responsible for arranging these bytes in the proper Little-Endian order for the program.
However, I have used the Long version of the Cached Mode functions (commented out in the latest code), and they work as well. In fact, there's a noticeable speed difference within my program when the Cached Mode functions are operating using Long transfers as opposed to Bytes.
Catalina provides a very nice utility called RamTest that allows you to verify operation of your memory drivers. In every case I've tried, the Cached Mode functions work, but the Direct Mode ones don't.
It's a mystery to me because both the Cached Mode and Direct Mode functions use the exact same memory command functions (SendWriteCmd or SendReadCmd) and data functions (SendRamData or GetRamData).
As you can see from the code listing there's not a lot of difference between the Cached Mode functions (XMM_WritePage or XMM_ReadPage) versus the Direct Mode functions (XMM_WriteLong/XMM_WriteMult or XMM_ReadLong/XMM_ReadMult), yet the former work fine while the latter don't. Or they are working but trash the serial display in the process..
Oh, in answer to a previous question, I haven't been able to try different serial baud rates because I don't know how to configure the RamTest Display to do that.
Sorry not to respond sooner - been away for a few days. And tomorrow I have to travel again, but I will take a few hours tonight to look at your code.
First, to respond to your very last issue (serial baud rates) - you can adjust the baud rate used by the RAM Test program by adjusting the value of SIO_BAUD in your CUSTOM.DEF file. You may want to try 230400 and see if that solves your problem. However, be aware that this will change ALL your serial baud rates, including the baud rate used by the various program loaders. So if you change it for RAM Test, you may also need to rebuild all the utilities, and also specify the new baud rate when using payload etc.
Your problem with the output of the RAM Test program could be simply that it is accessing RAM too fast and trying to output the serial I/O too fast for the baud rate to keep up. The serial I/O plugin used by the RAM Test program is specifically intended to be consumed by PropTerminal (available from http://www.insonix.ch/propeller/prop_term.html), and may not work well with other terminal emulators. I didn't write either the serial I/O plugin or the PropTerminal program, so I am not able to help much if this is misbehaving.
I will look at the other issues and post again in a few hours.
Ross.
OOPS - AN UPDATE: It looks like PropTerminal cannot be used with baud rates greater than 115200 baud. Upping the baud rate is still worth a try, but you will have to use another terminal program.
One thing occurred to me over night - you might try installing a clean copy of Catalina and trying your Custom XMM code with that. In all your experimenting, it seems possible you may have edited the source of either the kernel or the RAM test program.
I uninstalled Catalina and installed your latest release (3.16).
I copied over all of my CUSTOM files to the Target folder.
I went to the Utilities folder and typed:
build_ram_test CUSTOM CACHED_4K
(I wanted to verify RamTest is still happy with the Cached functions before attempting the Direct ones)
When it completed the task, without any errors by the way, I then typed: RamTest
And my PC responded:
'ramtest' is not recognized as an internal or external command, operable program or batch file
Sigh. I went back and checked all of the environment variables and both Catalina and Catalina/bin are still within the Windows PATH.
I then did a search for RamTest within the entire Catalina folder and Windows showed that the file didn't exist.
Any idea what happened to it? This is odd.
OK, so the RamTest idea didn't work because my PC can't find it.
I then decided to give build_utilities a try. I chose CUSTOM, no Flash, yes SRAM, and NO Cache.
Then I started Catalina, pulled up my MenuTest program, unchecked the 4K cache box, and compiled. No warnings, no errors, no problem. Then I chose Download To XMM RAM And Interact and...Nothing. So Catalina doesn't like the Direct functions.
I then went back to the build_utilities process but this time chose the 4K cache option. Went back to Catalina, checked the 4K Cache box, recompiled, chose Download to XMM RAM And Interact, and voila!, the Main Menu appeared.
So as before, the Cached functions work, but Direct didn't.
If I can ever locate RamTest maybe it can shed some light on this issue...
There is a separate "build_ram_test" batch file in the utilities folder. It will leave the binaries in that folder - you may have to manually copy them elsewhere.
Or, one can use this command after running build_ram_test CUSTOM (for testing in Direct Mode instead of Cached)
payload ram_test_pc -i
(BTW, I still can't find anything called RamTest anywhere within the Catalina folder. I don't know what happened to it, but I suppose I can create it as a batch file containing the above command)
Anyway, I was able to use the above command, and here's what I got for the TRIV Test:
And for the CMPX Test:
So the insanity persists. And I can't for the life of me figure out how my code is trashing the screen.
But whatever is happening, Catalina doesn't like Direct Mode either since, as I posted earlier, I get Nothing on the Interact Screen after downloading the compiled program to XMM memory.
I don't think the problem is that the RAM updates are being sent to the screen too fast, and thus causing the trashing. It's like a memory overwrite within RamTest itself is happening.
One other interesting issue: The Cached Functions don't work if I choose an 8K cache buffer. They work fine for 1K, 2K, or 4K, but not for 8K.
I don't know if this 8K cached problem is related, even tangentially, to the Direct Mode problem, but I find it to be strange as well...
I'm running the MenuTest program that I posted earlier on this forum. Not a lot going on with that program, so I assume that there's sufficient HubRam to work with. But I have no way to prove it right now.
I just tried the 1K cache option, and it did work for both RamTest and Catalina. However, the MenuTest screens have slowed to a crawl. In CMM the Fibonacci Menu (Menu 1) updates in about 1 sec. In XMM with 4K cache it updates in about 2 sec. And in XMM with 1K cache it takes 4.5 sec
My testing with the Cached functions indicates that a 4K cache is the "sweet spot". Reasonable performance while consuming only 4K of HubRam. I'll do some more experiments with 2K as it might be workable in the end. But 1K is definitely out, and 8K won't work.
Regarding the Direct Mode problem, is there any way I can comment out the XMM_Src and XMM_Dst lines and somehow pass the data to a known variable within the Kernel? I just want to verify that these items aren't somehow involved in overwriting critical memory within the Kernel and trashing the screen.
Maybe within the next few days we'll solve this screen trashing issue and get those Direct functions working...
Well, that's it for me tonight. It's past 1:00 AM here so I'm calling it quits for now.
I ran build_ram_test CUSTOM to create the binaries for testing in Direct Mode.
I then used Prop Terminal to load and execute the ram_test_pc.binary, and the result is the exact same screen trashing that your default terminal emulator had.
So it seems unlikely that the screen trashing is caused by the terminal emulators themselves.
It's odd how the screen output gets trashed by some simple routines that only fetch or put data to the XMM memory.
The XMM driver code has no interaction with the screen printing routines at all.
Yet, when I switch over to Cached Mode, which uses the exact same functions to read/write from/to the XMM Memory as Direct Mode, screen output is normal.
Maybe this one is auditioning for the next episode of Unsolved Mysteries
I got Catalina to work with the Direct Mode functions!
But the speed makes watching paint dry seem lightning fast by comparison
I ran my MenuTest program (posted earlier on this forum), and here's the Benchmark Speeds I get for displaying Menu 1 (the Fibonacci Screen):
CMM: 1.06 seconds
XMM SMALL Direct: 9.7 seconds XMM SMALL Cached 1K: 4.5 seconds XMM SMALL Cached 2K: 2.76 seconds XMM SMALL Cached 4K: 1.94 seconds XMM SMALL Cached 8K: Doesn't Work. No Response.
XMM LARGE Direct: 16.08 seconds XMM LARGE Cached 1K: 6.29 seconds XMM LARGE Cached 2K: 5.53 seconds XMM LARGE Cached 4K: 4.63 seconds XMM LARGE Cached 8K: Doesn't Work. No Response.
The only question left is why doesn't the 8K Cache Mode work.
But I'm not going to worry about it at this point. I got the answer to my question regarding Cached vs Direct Mode.
And my choice will be to go with the XMM SMALL Cached 4K option. This seems to be the sweet spot for acceptable speed with minimal HubRam usage.
This exercise also answered the question as to whether or not the Quad SRAM could operate in Direct Mode. It can, if you like watching paint dry. Otherwise, stick with the Cached Mode functions.
Now I will turn to writing the functions for the Flash RAM so I can store my XMM program and execute upon startup.
Many, many thanks to you for helping me resolve this issue. It's been a long time in coming.
Anybody who is crazy enough to want to use this code for anything is free to do so. I consider this code to be public domain. Why anyone would want to is another issue within itself that is beyond the scope of this posting...
Time for me to celebrate now with a nice cheeseburger
I've been thinking about the Flash RAM stuff, but then went back and re-read the Catalina manual discussing the various loaders. I came across this:
EEPROM.binary – TINY or CMM programs can be loaded to any 32kb EEPROM –
they do not need any special compile commands. XMM programs (SMALL or
LARGE) can be loaded to EEPROMs of 64Kb or larger, provided they are compiled
with the -C EEPROM option...XMM programs (SMALL or LARGE) can be loaded into EEPROM if compiled with
the EEPROM command line option:
catalina othello.c -lci -C C3 -C SMALL -C EEPROM
payload EEPROM Othello
Is this saying that if I replace the 64KB EEPROM on my Propeller Board with a larger capacity one (like the 256KB AT24CM02 that I have in my possession) that Catalina can store my program in it, then transfer it to SRAM upon startup and execute?
If so, then I don't need to fool with the Flash RAM stuff because the program can be stored in EEPROM.
I currently have 512KB of SRAM on my board (that's what this whole Cached vs Direct Mode circus has been about).
I could remove the existing 64KB EEPROM and replace it with two of these 256KB AT24CM02 EEPROMS on the I2C bus yielding a total of 512KB.
Then maybe Catalina can store my program in EEPROM, transfer it to SRAM upon bootup, and run it from there?
I just added it to my code, and now it passes RamTest in Direct Mode.
How in the blazes did I miss that?
Don't feel too bad. I missed it too!
However, I'm glad you finally got it sorted. I was beginning to worry you had found something fundamentally wrong with Catalina.
But I have spent a large part of today standing by the side of the road waiting for roadside assistance to turn up to tow my broken down car to the auto mechanic, so now that I am finally home I am going to have a couple of large whiskeys and go to bed
I've been thinking about the Flash RAM stuff, but then went back and re-read the Catalina manual discussing the various loaders. I came across this:
EEPROM.binary – TINY or CMM programs can be loaded to any 32kb EEPROM –
they do not need any special compile commands. XMM programs (SMALL or
LARGE) can be loaded to EEPROMs of 64Kb or larger, provided they are compiled
with the -C EEPROM option...XMM programs (SMALL or LARGE) can be loaded into EEPROM if compiled with
the EEPROM command line option:
catalina othello.c -lci -C C3 -C SMALL -C EEPROM
payload EEPROM Othello
Is this saying that if I replace the 64KB EEPROM on my Propeller Board with a larger capacity one (like the 256KB AT24CM02 that I have in my possession) that Catalina can store my program in it, then transfer it to SRAM upon startup and execute?
If so, then I don't need to fool with the Flash RAM stuff because the program can be stored in EEPROM.
I currently have 512KB of SRAM on my board (that's what this whole Cached vs Direct Mode circus has been about).
I could remove the existing 64KB EEPROM and replace it with two of these 256KB AT24CM02 EEPROMS on the I2C bus yielding a total of 512KB.
Then maybe Catalina can store my program in EEPROM, transfer it to SRAM upon bootup, and run it from there?
Am I understanding this correctly?
Thoughts?
While this should be possible in theory, I just checked the EEPROM loader code (Catalina_EEPROM_SIO_Loader.spin) and it says it can only handle EEPROMS up to 128k. I am not sure why - perhaps there simply were no larger EEPROMS available at the time.
Also, it may need tweaking to handle programming multiple EEPROMS.
The largest I2C EEPROM I've found is the 256KB Atmel AT24CM02.
I have several in my possession right now. These new chips also support a 1MHz "Fast Mode Plus" transfer rate.
A total of 2 of these can be placed on the same I2C bus, provided that the A2 pin on one is connected to ground, and the A2 pin on the other is connected to Vcc. This affects the addressing scheme so when you work it all out you will have a total of 512KB of EEPROM to play with.
Assuming the read and write command sequences for these new chips are backwards compatible with the previous generation, the biggest difference would be in the addressing bits sent as part of the command sequence.
Maybe later this week I can scan through the EEPROM loader code, find the 128KB restriction, and see if I can raise it.
I also need to verify that the Propeller can work with this larger 256KB EEPROM. Hopefully it can.
Although I want the full 512KB storage capability, I seriously doubt my finished code will be anywhere near that size. Even the 256KB is likely overkill.
Nevertheless, I still like the idea of 512KB just in case I need that extra margin.
I got Catalina to work with the Direct Mode functions!
But the speed makes watching paint dry seem lightning fast by comparison
I ran my MenuTest program (posted earlier on this forum), and here's the Benchmark Speeds I get for displaying Menu 1 (the Fibonacci Screen):
CMM: 1.06 seconds
XMM SMALL Direct: 9.7 seconds XMM SMALL Cached 1K: 4.5 seconds XMM SMALL Cached 2K: 2.76 seconds XMM SMALL Cached 4K: 1.94 seconds XMM SMALL Cached 8K: Doesn't Work. No Response.
XMM LARGE Direct: 16.08 seconds XMM LARGE Cached 1K: 6.29 seconds XMM LARGE Cached 2K: 5.53 seconds XMM LARGE Cached 4K: 4.63 seconds XMM LARGE Cached 8K: Doesn't Work. No Response.
...
Cheers,
Jeff
Congradulations. How many pins are you using? Do they have to be special pins like 0 and up for these speeds (I seem to remember those needs for ramblade). Please define SMALL and LARGE. What is CMM? Am I correct in assuming that the cache is in hub ram (don't know where else you would put 4k)? What do these numbers mean in MB/sec? What chips are you using?
Congradulations. How many pins are you using? Do they have to be special pins like 0 and up for these speeds (I seem to remember those needs for ramblade). Please define SMALL and LARGE. What is CMM? Am I correct in assuming that the cache is in hub ram (don't know where else you would put 4k)? What do these numbers mean in MB/sec? What chips are you using?
Thanks,
Hinv
Thanks. Getting the Cached Mode driver to work was relatively easy. The Direct Mode driver posed more challenges because of the available space within the Kernel to get it to work. But in the end both were working so I could run my comparison tests.
How many pins are you using?
I'm using a Quad SPI SRAM chip, so 6 pins total: 1 CS, 1 CLK, 4 Address/Command/Data.
Do they have to be special pins like 0 and up for these speeds (I seem to remember those needs for ramblade)
No. The CS and CLK pins can pretty much be whatever you want. The Data pins, however, must be in a contiguous block of 4. They don't have to start at 0. In fact, I will be moving them up to occupy pins 25 to 22. As long as the driver code knows where pin D0 is, it takes care of the I/O positioning issues.
Please define SMALL and LARGE. What is CMM?
These are memory models supported within Catalina. PropGCC does something similar: Compact Memory Model (CMM)=Code, Data, and Stack are within HubRam. Small Memory Model=Code is in XMM memory, Data and Stack are within HubRam. Large Memory Model=Code & Data in XMM memory, Stack within HubRam.
Note that CMM will be the fastest because everything is within HubRam. Large Memory Model will be slowest since only the Stack is within HubRam.
Am I correct in assuming that the cache is in hub ram (don't know where else you would put 4k)?
Yes, that is correct. The XMM data is copied into the HubRam Cache via a dedicated Caching Cog, and the Kernel executing your program fetches this information from the Cache.
What do these numbers mean in MB/sec?
I haven't done an actual benchmark on execution time, but we're looking at KB/sec not MB/sec.
I'm estimating that with the Caching enabled I'm seeing throughput rates of around 300KB/sec, with the rate varying somewhat depending upon how many bytes are fetched by the Caching Cog per cycle.
The XMM memory operates in Sequential Access Mode so fetching 512 bytes instead of 128 bytes per cycle will yield a slightly higher throughput because you will only have to send the read/write command and address location once per cycle as opposed to 4 times if 128 bytes are fetched.
At first glance the 300KB/sec speed isn't all that impressive, but it should be sufficient for my application.
What chips are you using?
I'm using the ISSI IS62/65WVS5128GBLL 512KX8 SPI SRAM chip that supports Quad Mode transfers. I bought them earlier this year from Mouser.com for a little more than $5 each. They appear to be a high demand item because they are still out of stock.
Regarding Cached versus Direct Mode: Unless you are using a Parallel Interface with separate Address and Data lines (not multiplexed and/or using latches) the Direct Mode won't buy you anything.
In fact, I found Direct Mode to be much slower than using the Cached Mode with these SPI SRAM chips.
Furthermore, given the Sequential Access Mode feature of these SPI SRAMs, I wouldn't be surprised if Cached Mode would beat the Parallel multiplexed/latched arrangement on data throughput.
In my case I can't spare the pins to go with separate Address and Data lines, so the Quad Mode SPI SRAM operating in Cached Mode was a reasonable compromise.
Well, all I say is that it is certainly feasible, and I am happy to will work with you to make it practical
Sounds good. I'll take you up on this offer at the appropriate time.
I bought a new USB Project Board from Parallax and decided to rearrange the XMM Memory and other components into a cleaner layout on this new board instead of the rats nest I have on my existing board.
As I await delivery of the ordered parts, I've moved on to writing various aspects of my Main application code...
… While keeping a close eye on the P2 testing and troubleshooting issues...
I finally modified my new Parallax USB Project Board with the XMM SRAM chips and an EEPROM.
The result is nothing like that clean and slick XMM memory board for the P2 designed by Von and posted by Chip on the P2 forum today, but it's good enough for testing
Here's the Top View:
This side uses "jumpers" to connect various "tracing" junctions on the other side of the board, as this was clearly a two-sided wiring job.
I used the breadboard as an insulator to keep these "jumpers" from accidentally shorting out anything on the top side. Plus the breadboard gives it an interesting if not quaint look.
The two chips on the left side of the breadboard are the ISSI 65WVS5128GBLL 512KB X 8 SPI SRAM chips. That single chip toward the center is the Atmel AT24CM02 256KB EEPROM chip.
The resistors you see are pullups for the SRAM CLK and CS, and the SDA and SCL for the EEPROM.
If you look closely you can see that I removed the 64KB EEPROM from the USB Board.
Parallax might be happy to know that this 256KB EEPROM does work with the Propeller. I'm able to store my CMM programs on it and the Propeller does load and execute the code upon startup. Seeing that it does work is a big relief.
Now here's Underside:
This side I used "tracing" to connect the components together by directly soldering copper wires to the various donut holes.
Regarding those 2 SRAM chips: I shamelessly ripped off Rayman's Rampage2 idea but deleted the Flash chips as I want my code to be stored on the EEPROM and execute from there upon bootup.
Each SRAM transfers a single nibble per read/write clock cycle, but by combining these nibbles onto the 8-bit bus one effectively transfers a single byte per clock cycle.
There is a noticeable speed difference when running XMM programs using this technique compared to the single nibble transfer when using only one SRAM like on my previous USB Project Board.
I wrote the CUSTOM_XMM driver (attached) to take advantage of this byte transfer arrangement. As long as the caching cog is transferring an even number of bytes at all times, then there shouldn't be any problems.
That being said, let's move on to running a program. For this test, I again used the MenuTest program (posted previously on this forum). In this case I configured it to run in CMM Mode.
I compiled the program and here's the build results:
I then used the Download To EEPROM command under Tools in Code::Blocks:
No problems there. I then ran the program, went through the Menu Screens, chose the Fibonacci Screen, and got this:
Very good. Working fine.
I then reconfigured Catalina to compile this using the SMALL XMM memory model with 4K cache. Keep in mind that build_utilities was already configured for this memory model.
Initially, I didn't select the EEPROM loader under Build Options. Here's the compile results:
So it compiled fine. Then, just as an experiment, I then attempted to Download To EEPROM and got this:
OK, so it failed. I expected that.
I then tried Download To XMM RAM And Interact. I went through the Menus and again selected the Fibonacci Screen. Here's how it looked:
Notice the screen update speed difference between XMM (1.6702 secs) versus CMM (1.0664). Not lightning fast, but acceptable for my purposes.
Then, I went back, modified the Build Options to include the EEPROM loader, recompiled, and got this:
Great, it compiled. Then, I attempted the Download To EEPROM again and got this:
Alright, it also failed. I also noticed that when using the EEPROM loader option, the Download To XMM RAM And Interact no longer works.
I know I'm doing something wrong here because it should be able to store my code in the EEPROM as it's much smaller than the 128KB limit the EEPROM loader supports. But I'm having a mental block and don't know what I should try next.
I would welcome your thoughts and suggestions on this. The hardware appears to be working but somewhere along the line I'm not configuring it correctly to store the XMM code in EEPROM.
Alright, it also failed. I also noticed that when using the EEPROM loader option, the Download To XMM RAM And Interact no longer works.
I know I'm doing something wrong here because it should be able to store my code in the EEPROM as it's much smaller than the 128KB limit the EEPROM loader supports. But I'm having a mental block and don't know what I should try next.
I would welcome your thoughts and suggestions on this. The hardware appears to be working but somewhere along the line I'm not configuring it correctly to store the XMM code in EEPROM.
The "Download to EEPROM" menu item only works for normal programs (i.e. size<= 32kb), not XMM programs. It executes a command like:
payload -e Your_program
However, the "Download to XMM RAM and Interact" menu item is not what you want either - it uses the XMM loader, not the EEPROM loader. It actually executes a command like:
payload XMM Your_program -i
What you want is to download an XMM program to EEPROM (not XMM RAM) which requires that you build your program with -C EEPROM (which includes the code that loads your program from the EEPROM to XMM RAM **), but then use a command to program the EEPROM like:
payload EEPROM Your_program -i
But I don't have a preconfigured Code::Blocks menu item for that. My bad
You have a few options:
1. Use the command line.
2. Edit the "Download to XMM RAM and Interact" menu item (this is pretty easy to do in Code::Blocks - see "Tool->Configure Tools")
3. Add another "Download XMM to EEPROM and Interact" menu item (ditto).
I'd suggest you try (1) first, to make sure this solves the problem. Then either (2) or (3) for convenience.
Ross.
** I used to have code that would execute XMM SMALL programs directly from the EEPROM, instead of first loading them to XMM RAM, but it seems to have gotten lost somewhere along the line. I was sure it was in one of the very last of the Catalina P1 releases, but I have tried to find it and cannot. It may have been in a release that never actually got issued. It was just an implementation of the XMM API that read code direct from EEPROM (above the first 32kb) instead of from SRAM or FLASH. It wasn't particularly useful since it was generally slower than executing from XMM RAM and it could only be used for SMALL programs, but for completeness I may re-write it one day.
What you want is to download an XMM program to EEPROM (not XMM RAM) which requires that you build your program with -C EEPROM (which includes the code that loads your program from the EEPROM to XMM RAM **), but then use a command to program the EEPROM like:
payload EEPROM Your_program -i
But I don't have a preconfigured Code::Blocks menu item for that. My bad
You have a few options:
1. Use the command line.
2. Edit the "Download to XMM RAM and Interact" menu item (this is pretty easy to do in Code::Blocks - see "Tool->Configure Tools")
3. Add another "Download XMM to EEPROM and Interact" menu item (ditto).
I'd suggest you try (1) first, to make sure this solves the problem. Then either (2) or (3) for convenience.
Ross.
OK, for this test I will try the Command Line option since it's the easiest and quickest.
But first, making sure the EEPROM loader is included as part of the Build Options, and then compiling I get this:
It compiled the MenuTest program as an XMM SMALL with 4K Cache and included the EEPROM loader. So far, so good.
Next, I invoked a Command Prompt menu, made sure it was in the correct MenuTest directory, then did this:
Oops. It says it can't find the Secondary Loader.
Maybe the EEPROM loader wasn't included even though it said it was?
Or maybe the EEPROM loader won't work with the 256KB EEPROM?
I know for a fact Catalina can and does store CMM programs to this 256KB EEPROM without a problem because I've done it many times.
I also know that the CMM program was stored correctly in the 256KB EEPROM because it loads and executes correctly upon bootup.
Maybe the EEPROM loader has a problem accessing the EEPROM beyond 32KB, although just glancing at it the loader shouldn't have any problems at all accessing up to 64KB.
Let's take a quick look at three EEPROMs currently on the market: 64KB, 128KB, and 256KB.
For the 24LC512 EEPROM (64KB), the command/address scheme is this:
Here the A2 and A1 in the Control Byte are hardware select lines allowing a maximum of 4 of these EEPROMs to be placed on the I2C bus. The A0 in the 24LC512 Command Byte has been replaced with address line A16 in the AT24CM01.
Finally, for the AT24CM02 (256KB) EEPROM the command/address scheme is this:
Here the A2 in the Control Byte is the only hardware select line allowing only 2 of these EEPROMS to be placed on the I2C bus. The Command Byte A1 and A0 in the 24LC512 has been replaced with actual address lines A17 and A16 in the AT24CM02.
So if Industry ever develops a 512KB EEPROM, then that final A2 in the Command Byte will be replaced with address line A18, with a resulting downside that only a single device can be placed on the I2C bus. But for the Prop1 board that doesn't matter because only a single EEPROM is on the I2C bus as it is.
Anyway, the MenuTest program, including its Loader, checks in at less than 64KB, so it seems to me it should have been stored within the 256KB EEPROM without a problem since the A2, A17, and A16 values within the Control Byte should all be Zeros.
Odd. The secondary loader is just the EEPROM.binary program (the primary loader is the one built into the Propeller). Even if the code doesn't load or run correctly, the secondary loader should be correctly detected by payload.
Here is an example of what I see when I use it:
C:\Program Files (x86)\Catalina_3.13.2\demos>payload eeprom othello.binary
Using Propeller (version 1) on port COM19 for first download
Using Secondary Loader on port COM19 for subsequent download
I suspect that the EEPROM loader is failing as soon as it tries to talk to the EEPROM. Can you try your payload command with a -d option and post the output? That may tell us.
I'm getting ready to call it a night but I ran the Loader with the -d option.
Here is the result:
C:\WorkCode\Catalina\XMM\MenuTest\24Aug19>payload EEPROM MenuTest -d
Catalina Payload 3.14
diagnostic level 1
executable name = payload
Loading Propeller binary EEPROM
Error: Unable to open local file EEPROM.binary
- trying bin directory
File size = 5264
baudrate = 115200
timeout = 250
sync timeout = 100
reset delay = 0
interfile delay = 500
Trying COM1 ... unable to open comport
error 1 opening port 0
Trying COM2 ... unable to open comport
error 1 opening port 1
Trying COM3 ... unable to open comport
error 1 opening port 2
Trying COM4 ... opened port 3
Using Propeller (version 1) on port COM4 for first download
Downloading normal binary file EEPROM
Response = 0xfe
Trying COM1 ... unable to open comport
error 1 opening port 0
Trying COM2 ... unable to open comport
error 1 opening port 1
Trying COM3 ... unable to open comport
error 1 opening port 2
Trying COM4 ... opened port 3
Sending page 00000000
Warning: no sync received
Trying COM5 ... unable to open comport
error 1 opening port 4
Trying COM6 ... unable to open comport
error 1 opening port 5
Trying COM7 ... unable to open comport
error 1 opening port 6
Trying COM8 ... unable to open comport
error 1 opening port 7
Trying COM9 ... unable to open comport
error 1 opening port 8
Trying COM10 ... unable to open comport
error 1 opening port 9
Trying COM11 ... unable to open comport
error 1 opening port 10
Trying COM12 ... unable to open comport
error 1 opening port 11
Trying COM13 ... unable to open comport
error 1 opening port 12
Trying COM14 ... unable to open comport
error 1 opening port 13
Trying COM15 ... unable to open comport
error 1 opening port 14
Trying COM16 ... unable to open comport
error 1 opening port 15
Trying COM17 ... unable to open comport
error 1 opening port 16
Trying COM18 ... unable to open comport
error 1 opening port 17
Trying COM19 ... unable to open comport
error 1 opening port 18
Trying COM20 ... unable to open comport
error 1 opening port 19
Trying COM21 ... unable to open comport
error 1 opening port 20
Trying COM22 ... unable to open comport
error 1 opening port 21
Trying COM23 ... unable to open comport
error 1 opening port 22
Trying COM24 ... unable to open comport
error 1 opening port 23
Trying COM25 ... unable to open comport
error 1 opening port 24
Trying COM26 ... unable to open comport
error 1 opening port 25
Trying COM27 ... unable to open comport
error 1 opening port 26
Trying COM28 ... unable to open comport
error 1 opening port 27
Trying COM29 ... unable to open comport
error 1 opening port 28
Trying COM30 ... unable to open comport
error 1 opening port 29
Trying COM31 ... unable to open comport
error 1 opening port 30
Trying COM32 ... unable to open comport
error 1 opening port 31
No Secondary Loader found on any port
C:\WorkCode\Catalina\XMM\MenuTest\24Aug19>
I don't know what the 0xfe response means from the initial Propeller Loader, but I assume it's correct?
Then it says it's having a Sync problem with the Secondary EEPROM Loader.
I don't remember if it was a Sync Error that I got last month while attempting to use the Flash Loader, but I do know it was unsuccessful because the Flash chip didn't support all of the commands needed to properly implement the Flash API functions.
In fact, that Flash problem prompted me to pursue the EEPROM route and dispense with the Flash chip completely.
On a related note, I've never had a problem with the XMM SRAM Loader as it worked every time I tried it. I use this all the time when testing and debugging my XMM code.
So getting back to the unanswered question with the EEPROM Loader: What is causing the Sync Error?
So getting back to the unanswered question with the EEPROM Loader: What is causing the Sync Error?
Thanks. The sync error is misleading. Here is the important bit:
Sending page 00000000
Warning: no sync received
Here is what I get in similar circumstances:
Sending page 00000000
Sync received
LRC received - 0x00
Using Secondary Loader on port COM9 for subsequent download
The sync error is because payload is trying to send a page of data to be programmed into EEPROM (it knows the program is intended for the EEPROM), but the EEPROM.binary program (which we just loaded, and which is supposed to accept the page and then program it) is apparently locking up and not sending back a response. So in this case, the message "No Secondary Loader found on any port" is a little misleading - it just means no working secondary loader was found.
This is what I thought - but I wanted to confirm it before I started digging. I need to figure out why the EEPROM loader is not responding. I need to have a look at the code, and maybe add some diagnostics. Most likely, the chip is just not responding to the commands being sent in the way the program expects. I will also have to look at the EEPROM chip specs. This may take some time - it's been years since I looked at that code.
I'll keep you posted, but if you have something else to get on with in the meantime, I'd suggest you do so.
Comments
I have sometimes the opposite effect, chars with spaces in between. As much as I praise Spin2Gui and Fastspin there is some issue with the terminal of P2load. I had no time to figure this out but I had some strange experiences the last week while fighting to integrate TAQOZ and Fastpin compiled stuff.
My current theory is that the terminal is effing up on some character combinations. I had a couple of times the situation that I needed to HEX out the data or the Terminal misbehaves.
Since my goal is somewhere else I just live with it and hex- out when problems arrive.
But maybe you are fighting windmills, your program is fine, the output of the Terminal f..es up sometimes.
I have not investigated this deep, but P2loads Terminal is - hmm - misbehaving sometimes.
Mike.
It could be some problem with the loader, but it's more likely that some memory within the XMM Kernel itself is being overwritten somehow.
Here's some sample code that writes to XMM Memory via the Cache (which works fine):
XMM_WritePage andn outa,RamSel 'RamSel=Lo (SRAM Active) call #SendWriteCmd 'Configure SRAM For Writing :HubData rdbyte RamData,Hub_Addr 'HubRam -> RamData (This Is A Byte) mov RamLoop,#02 'RamLoop=2 (Send 2 Nibbles To SRAM) call #SendRamData 'RamData -> SRAM add Hub_Addr,#01 'Hub_Addr=Hub_Addr + 1 add XMM_Addr,#01 'XMM_Addr=XMM_Addr + 1 djnz XMM_Len,#:HubData 'if(--XMM_Len > 0) goto HubData or outa,RamSel 'RamSel=Hi (SRAM Inactive) XMM_WritePage_ret ret 'ReturnNotations:
XMM_Len: Number of Bytes to write to SRAM
Hub_Addr: Hub Address location from which the Bytes are to be fetched.
XMM_Addr: The SRAM location to which the Bytes are to be written.
The SendWriteCmd function is benign. It simply sends the SRAM Write Command ($02) with the address appended to it (for example, $0207ABCD) to the SRAM stating that it wants to write data to it at address $07ABCD.
The SendRamData function writes a Byte to this location (with the Byte sent as 2 Nibbles because this is a 4-bit data bus).
Now, here's the code to write to XMM Memory in Direct Mode (which doesn't work):
XMM_WriteLong mov XMM_Len,#04 'XMM_Len=4 (Write Long) XMM_WriteMult andn outa,RamSel 'RamSel=Lo (SRAM Active) call #SendWriteCmd 'Configure SRAM For Writing add XMM_Addr,XMM_Len 'XMM_Addr=XMM_Addr + XMM_Len XMM_Src mov RamData,0-0 'CogRam -> RamData shl XMM_Len,#01 'XMM_Len (Bytes) -> XMM_Len(Nibbles) mov RamLoop,XMM_Len 'RamLoop=XMM_Len (Write Nibbles) call #SendRamData 'RamData -> SRAM or outa,RamSel 'RamSel=Hi (SRAM Inactive) XMM_WriteMult_ret XMM_WriteLong_ret ret 'ReturnIn Direct Mode, XMM_Len can only have values of 1,2, or 4.
Notice that the exact same two functions used during Cache write (SendWriteCmd and SendRamData) are used here as well.
In this case the HubRam isn't used, so the Byte(s) are fetched from a CogRam location specified by the Kernel:
With the 0-0 overwrittten by the Kernel via the MOVS instruction thus pointing to the CogRam location.
The XMM Read Function, which works in Cached mode is this:
XMM_ReadPage andn outa,RamSel 'RamSel=Lo (SRAM Active) call #SendReadCmd 'Configure SRAM For Reading :XmmData mov RamLoop,#02 'RamLoop=2 (Grab 2 SRAM Nibbles) call #GetRamData 'SRAM -> RamData wrbyte RamData,Hub_Addr 'RamData -> HubRam add Hub_Addr,#01 'Hub_Addr=Hub_Addr + 1 add XMM_Addr,#01 'XMM_Addr=XMM_Addr + 1 djnz XMM_Len,#:XmmData 'if(--XMM_Len > 0) goto XmmData or outa,RamSel 'RamSel=Hi (SRAM Inactive) XMM_ReadPage_ret ret 'ReturnNotations:
XMM_Len: Number of Bytes to read from SRAM
XMM_Addr: The SRAM location from which the Bytes are to be fetched.
Hub_Addr: Hub Address location to which the Bytes are to be written
The SendReadCmd is just like the SendWriteCmd, except it uses a $03 (read) instead of the $02 (write) command prefix. It's followed by the address (for example, $0307ABCD) and sent to the SRAM stating that it wants to read data from this address.
The GetRamData function reads a Byte from this location (with the Byte reconstructed from two successive Nibble reads, again due to the 4-bit data bus)
Now, here's the Direct Read Function, which doesn't work:
XMM_ReadLong mov XMM_Len,#04 'XMM_Len=4 (Read A Long) XMM_ReadMult andn outa,RamSel 'RamSel=Lo (SRAM Active) call #SendReadCmd 'Configure SRAM For Reading add XMM_Addr,XMM_Len 'XMM_Addr=XMM_Addr + XMM_Len shl XMM_Len,#01 'XMM_Len (Bytes)->XMM_Len (Nibbles) mov RamLoop,XMM_Len 'RamLoop=XMM_Len (Read Nibbles) call #GetRamData 'SRAM -> RamData XMM_Dst mov 0-0,RamData 'RamData -> CogRam or outa,RamSel 'RamSel=Hi (SRAM Inactive) XMM_ReadMult_ret XMM_ReadLong_ret ret 'ReturnWith XMM_Len once again restricted to values of 1,2, or 4 in Direct Mode.
Notice how it uses the exact same two functions (SendReadCmd and GetRamData) that the Cached function uses.
Again, the HubRam isn't used, so the Byte(s) are to be written to a CogRam location specified by the Kernel:
With the 0-0 overwritten by the Kernel via the MOVD instruction thus pointing to the CogRam location.
There's nothing mysterious with the SendWriteCmd, SendRamData, SendReadCmd, and GetRamData functions, so I'm just wondering if the MOVS and MOVD process within the Kernel is somehow overwriting portions of the Kernel itself and trashing the screen...
Yes, it is a good idea to have more than one terminal, for simple 'sanity checks'.
..
Well spotted. It is not 'trashing' in the classic sense, as there is no garbage appearing. It's a somewhat well behaved failure.
The effect is consistent with code being too fast for a serial reporting link - how does it change, if you change the BAUD rate ?
We don't see the code that uses XMM_Addr so I can't tell if it is truly relevant, but in the Cache version it is incremented by one for each time through the loop, while in the Direct version it is updated once prior to the call that transfers the data. For bytes XMM_Addr should update at the same rate, so do byte transfers work with both methods? What size transfers are used in the test that corrupts the display?
I've attached the latest XMM driver functions for review.
The XMM_Addr, Hub_Addr, and XMM_Len variables are provided to my functions by the Kernel and outside the control of my driver. If there was a way to capture this information it would be helpful for troubleshooting.
In Direct Mode the XMM_Len value is restricted to 1,2, or 4 bytes per function call. I know for instruction fetches this value is always 4, but I don't know what the most common value is for data transfers. That's a question @RossH can answer.
Since my Direct Mode functions don't mess with XMM_Len (aside from copying its value into the RamLoop variable -- then converting RamLoop into Nibbles), it doesn't really matter where in the function that XMM_Len is added to XMM_Addr. In the examples above it's added near the start of the function, but in my latest code it's added at the end of the function. It makes no difference as far as the test failure goes.
In Cached Mode the value of XMM_Len can be much greater than 4, likely hundreds (or maybe thousands) of Bytes, as requested by the Kernel. In this case my functions simply increment both Hub_Addr and XMM_Addr by one during each iteration through the loop. The final result is that both XMM_Addr and Hub_Addr have both been incremented by XMM_Len, similar to how the XMM_Addr value has been incremented by XMM_Len in the Direct Mode functions.
The Loader uses the Cached Mode functions to transfer the program to the propeller. In my latest code it transfers single bytes, so the Loader is responsible for arranging these bytes in the proper Little-Endian order for the program.
However, I have used the Long version of the Cached Mode functions (commented out in the latest code), and they work as well. In fact, there's a noticeable speed difference within my program when the Cached Mode functions are operating using Long transfers as opposed to Bytes.
Catalina provides a very nice utility called RamTest that allows you to verify operation of your memory drivers. In every case I've tried, the Cached Mode functions work, but the Direct Mode ones don't.
It's a mystery to me because both the Cached Mode and Direct Mode functions use the exact same memory command functions (SendWriteCmd or SendReadCmd) and data functions (SendRamData or GetRamData).
As you can see from the code listing there's not a lot of difference between the Cached Mode functions (XMM_WritePage or XMM_ReadPage) versus the Direct Mode functions (XMM_WriteLong/XMM_WriteMult or XMM_ReadLong/XMM_ReadMult), yet the former work fine while the latter don't. Or they are working but trash the serial display in the process..
Oh, in answer to a previous question, I haven't been able to try different serial baud rates because I don't know how to configure the RamTest Display to do that.
Sorry not to respond sooner - been away for a few days. And tomorrow I have to travel again, but I will take a few hours tonight to look at your code.
First, to respond to your very last issue (serial baud rates) - you can adjust the baud rate used by the RAM Test program by adjusting the value of SIO_BAUD in your CUSTOM.DEF file. You may want to try 230400 and see if that solves your problem. However, be aware that this will change ALL your serial baud rates, including the baud rate used by the various program loaders. So if you change it for RAM Test, you may also need to rebuild all the utilities, and also specify the new baud rate when using payload etc.
Your problem with the output of the RAM Test program could be simply that it is accessing RAM too fast and trying to output the serial I/O too fast for the baud rate to keep up. The serial I/O plugin used by the RAM Test program is specifically intended to be consumed by PropTerminal (available from http://www.insonix.ch/propeller/prop_term.html), and may not work well with other terminal emulators. I didn't write either the serial I/O plugin or the PropTerminal program, so I am not able to help much if this is misbehaving.
I will look at the other issues and post again in a few hours.
Ross.
OOPS - AN UPDATE: It looks like PropTerminal cannot be used with baud rates greater than 115200 baud. Upping the baud rate is still worth a try, but you will have to use another terminal program.
Hello @Wingineer.
I've been looking at this code for a couple of hours now, and I can't see what is going wrong
I'll try again tomorrow.
Ross.
One thing occurred to me over night - you might try installing a clean copy of Catalina and trying your Custom XMM code with that. In all your experimenting, it seems possible you may have edited the source of either the kernel or the RAM test program.
Ross.
Welcome back!
I uninstalled Catalina and installed your latest release (3.16).
I copied over all of my CUSTOM files to the Target folder.
I went to the Utilities folder and typed:
build_ram_test CUSTOM CACHED_4K
(I wanted to verify RamTest is still happy with the Cached functions before attempting the Direct ones)
When it completed the task, without any errors by the way, I then typed: RamTest
And my PC responded:
'ramtest' is not recognized as an internal or external command, operable program or batch file
Sigh. I went back and checked all of the environment variables and both Catalina and Catalina/bin are still within the Windows PATH.
I then did a search for RamTest within the entire Catalina folder and Windows showed that the file didn't exist.
Any idea what happened to it? This is odd.
OK, so the RamTest idea didn't work because my PC can't find it.
I then decided to give build_utilities a try. I chose CUSTOM, no Flash, yes SRAM, and NO Cache.
Then I started Catalina, pulled up my MenuTest program, unchecked the 4K cache box, and compiled. No warnings, no errors, no problem. Then I chose Download To XMM RAM And Interact and...Nothing. So Catalina doesn't like the Direct functions.
I then went back to the build_utilities process but this time chose the 4K cache option. Went back to Catalina, checked the 4K Cache box, recompiled, chose Download to XMM RAM And Interact, and voila!, the Main Menu appeared.
So as before, the Cached functions work, but Direct didn't.
If I can ever locate RamTest maybe it can shed some light on this issue...
I miss RamTest
Jeff
There is a separate "build_ram_test" batch file in the utilities folder. It will leave the binaries in that folder - you may have to manually copy them elsewhere.
Ross.
Or, one can use this command after running build_ram_test CUSTOM (for testing in Direct Mode instead of Cached)
payload ram_test_pc -i
(BTW, I still can't find anything called RamTest anywhere within the Catalina folder. I don't know what happened to it, but I suppose I can create it as a batch file containing the above command)
Anyway, I was able to use the above command, and here's what I got for the TRIV Test:
And for the CMPX Test:
So the insanity persists. And I can't for the life of me figure out how my code is trashing the screen.
But whatever is happening, Catalina doesn't like Direct Mode either since, as I posted earlier, I get Nothing on the Interact Screen after downloading the compiled program to XMM memory.
I don't think the problem is that the RAM updates are being sent to the screen too fast, and thus causing the trashing. It's like a memory overwrite within RamTest itself is happening.
One other interesting issue: The Cached Functions don't work if I choose an 8K cache buffer. They work fine for 1K, 2K, or 4K, but not for 8K.
I don't know if this 8K cached problem is related, even tangentially, to the Direct Mode problem, but I find it to be strange as well...
The reason CACHED_8K doesn't work is probably unrelated. It may simply be a space issue. Does your program have 8kb of Hub RAM spare?
The other problem is also driving me crazy. But we'll solve it!
And, just thinking about it - have you tried a cache size of CACHED_1K to see if that works?
Ross.
I'm running the MenuTest program that I posted earlier on this forum. Not a lot going on with that program, so I assume that there's sufficient HubRam to work with. But I have no way to prove it right now.
I just tried the 1K cache option, and it did work for both RamTest and Catalina. However, the MenuTest screens have slowed to a crawl. In CMM the Fibonacci Menu (Menu 1) updates in about 1 sec. In XMM with 4K cache it updates in about 2 sec. And in XMM with 1K cache it takes 4.5 sec
My testing with the Cached functions indicates that a 4K cache is the "sweet spot". Reasonable performance while consuming only 4K of HubRam. I'll do some more experiments with 2K as it might be workable in the end. But 1K is definitely out, and 8K won't work.
Regarding the Direct Mode problem, is there any way I can comment out the XMM_Src and XMM_Dst lines and somehow pass the data to a known variable within the Kernel? I just want to verify that these items aren't somehow involved in overwriting critical memory within the Kernel and trashing the screen.
Maybe within the next few days we'll solve this screen trashing issue and get those Direct functions working...
Well, that's it for me tonight. It's past 1:00 AM here so I'm calling it quits for now.
Just a quick update here.
I ran build_ram_test CUSTOM to create the binaries for testing in Direct Mode.
I then used Prop Terminal to load and execute the ram_test_pc.binary, and the result is the exact same screen trashing that your default terminal emulator had.
So it seems unlikely that the screen trashing is caused by the terminal emulators themselves.
It's odd how the screen output gets trashed by some simple routines that only fetch or put data to the XMM memory.
The XMM driver code has no interaction with the screen printing routines at all.
Yet, when I switch over to Cached Mode, which uses the exact same functions to read/write from/to the XMM Memory as Direct Mode, screen output is normal.
Maybe this one is auditioning for the next episode of Unsolved Mysteries
I found something in CUSTOM_XMM.inc.
Take a look here:
XMM_Activate or dira,RamSigs 'Enable RamClk,RamSel,D3,D0 or outa,RamSigs 'Set RamClk=1,RamSel=1,D3=1,D0=1 call #MakeQuadMode 'Switch To Quad Mode XMM_Activate_retNotice anything missing?
Like maybe a ret at the end of this function?
I just added it to my code, and now it passes RamTest in Direct Mode.
How in the blazes did I miss that?
And how in the world did it work in Cached Mode with this critical piece missing?
I'm past due for an Eye Exam so maybe I better snap to it...
But, it still doesn't work in Catalina.
So, I'll continue to experiment...
Success!
I got Catalina to work with the Direct Mode functions!
But the speed makes watching paint dry seem lightning fast by comparison
I ran my MenuTest program (posted earlier on this forum), and here's the Benchmark Speeds I get for displaying Menu 1 (the Fibonacci Screen):
CMM: 1.06 seconds
XMM SMALL Direct: 9.7 seconds
XMM SMALL Cached 1K: 4.5 seconds
XMM SMALL Cached 2K: 2.76 seconds
XMM SMALL Cached 4K: 1.94 seconds
XMM SMALL Cached 8K: Doesn't Work. No Response.
XMM LARGE Direct: 16.08 seconds
XMM LARGE Cached 1K: 6.29 seconds
XMM LARGE Cached 2K: 5.53 seconds
XMM LARGE Cached 4K: 4.63 seconds
XMM LARGE Cached 8K: Doesn't Work. No Response.
The only question left is why doesn't the 8K Cache Mode work.
But I'm not going to worry about it at this point. I got the answer to my question regarding Cached vs Direct Mode.
And my choice will be to go with the XMM SMALL Cached 4K option. This seems to be the sweet spot for acceptable speed with minimal HubRam usage.
This exercise also answered the question as to whether or not the Quad SRAM could operate in Direct Mode. It can, if you like watching paint dry. Otherwise, stick with the Cached Mode functions.
Now I will turn to writing the functions for the Flash RAM so I can store my XMM program and execute upon startup.
Many, many thanks to you for helping me resolve this issue. It's been a long time in coming.
Anybody who is crazy enough to want to use this code for anything is free to do so. I consider this code to be public domain. Why anyone would want to is another issue within itself that is beyond the scope of this posting...
Time for me to celebrate now with a nice cheeseburger
Cheers,
Jeff
Well I'm back at it again, stirring up trouble
I've been thinking about the Flash RAM stuff, but then went back and re-read the Catalina manual discussing the various loaders. I came across this:
Is this saying that if I replace the 64KB EEPROM on my Propeller Board with a larger capacity one (like the 256KB AT24CM02 that I have in my possession) that Catalina can store my program in it, then transfer it to SRAM upon startup and execute?
If so, then I don't need to fool with the Flash RAM stuff because the program can be stored in EEPROM.
I currently have 512KB of SRAM on my board (that's what this whole Cached vs Direct Mode circus has been about).
I could remove the existing 64KB EEPROM and replace it with two of these 256KB AT24CM02 EEPROMS on the I2C bus yielding a total of 512KB.
Then maybe Catalina can store my program in EEPROM, transfer it to SRAM upon bootup, and run it from there?
Am I understanding this correctly?
Thoughts?
Don't feel too bad. I missed it too!
However, I'm glad you finally got it sorted. I was beginning to worry you had found something fundamentally wrong with Catalina.
But I have spent a large part of today standing by the side of the road waiting for roadside assistance to turn up to tow my broken down car to the auto mechanic, so now that I am finally home I am going to have a couple of large whiskeys and go to bed
I'll look at the rest of your posts tomorrow!
Ross.
While this should be possible in theory, I just checked the EEPROM loader code (Catalina_EEPROM_SIO_Loader.spin) and it says it can only handle EEPROMS up to 128k. I am not sure why - perhaps there simply were no larger EEPROMS available at the time.
Also, it may need tweaking to handle programming multiple EEPROMS.
Ross.
The largest I2C EEPROM I've found is the 256KB Atmel AT24CM02.
I have several in my possession right now. These new chips also support a 1MHz "Fast Mode Plus" transfer rate.
A total of 2 of these can be placed on the same I2C bus, provided that the A2 pin on one is connected to ground, and the A2 pin on the other is connected to Vcc. This affects the addressing scheme so when you work it all out you will have a total of 512KB of EEPROM to play with.
Assuming the read and write command sequences for these new chips are backwards compatible with the previous generation, the biggest difference would be in the addressing bits sent as part of the command sequence.
Maybe later this week I can scan through the EEPROM loader code, find the 128KB restriction, and see if I can raise it.
I also need to verify that the Propeller can work with this larger 256KB EEPROM. Hopefully it can.
Although I want the full 512KB storage capability, I seriously doubt my finished code will be anywhere near that size. Even the 256KB is likely overkill.
Nevertheless, I still like the idea of 512KB just in case I need that extra margin.
Jeff
Well, all I say is that it is certainly feasible, and I am happy to will work with you to make it practical
Congradulations. How many pins are you using? Do they have to be special pins like 0 and up for these speeds (I seem to remember those needs for ramblade). Please define SMALL and LARGE. What is CMM? Am I correct in assuming that the cache is in hub ram (don't know where else you would put 4k)? What do these numbers mean in MB/sec? What chips are you using?
Thanks,
Hinv
Thanks. Getting the Cached Mode driver to work was relatively easy. The Direct Mode driver posed more challenges because of the available space within the Kernel to get it to work. But in the end both were working so I could run my comparison tests.
I'm using a Quad SPI SRAM chip, so 6 pins total: 1 CS, 1 CLK, 4 Address/Command/Data.
No. The CS and CLK pins can pretty much be whatever you want. The Data pins, however, must be in a contiguous block of 4. They don't have to start at 0. In fact, I will be moving them up to occupy pins 25 to 22. As long as the driver code knows where pin D0 is, it takes care of the I/O positioning issues.
These are memory models supported within Catalina. PropGCC does something similar:
Compact Memory Model (CMM)=Code, Data, and Stack are within HubRam.
Small Memory Model=Code is in XMM memory, Data and Stack are within HubRam.
Large Memory Model=Code & Data in XMM memory, Stack within HubRam.
Note that CMM will be the fastest because everything is within HubRam. Large Memory Model will be slowest since only the Stack is within HubRam.
Yes, that is correct. The XMM data is copied into the HubRam Cache via a dedicated Caching Cog, and the Kernel executing your program fetches this information from the Cache.
I haven't done an actual benchmark on execution time, but we're looking at KB/sec not MB/sec.
I'm estimating that with the Caching enabled I'm seeing throughput rates of around 300KB/sec, with the rate varying somewhat depending upon how many bytes are fetched by the Caching Cog per cycle.
The XMM memory operates in Sequential Access Mode so fetching 512 bytes instead of 128 bytes per cycle will yield a slightly higher throughput because you will only have to send the read/write command and address location once per cycle as opposed to 4 times if 128 bytes are fetched.
At first glance the 300KB/sec speed isn't all that impressive, but it should be sufficient for my application.
I'm using the ISSI IS62/65WVS5128GBLL 512KX8 SPI SRAM chip that supports Quad Mode transfers. I bought them earlier this year from Mouser.com for a little more than $5 each. They appear to be a high demand item because they are still out of stock.
Regarding Cached versus Direct Mode: Unless you are using a Parallel Interface with separate Address and Data lines (not multiplexed and/or using latches) the Direct Mode won't buy you anything.
In fact, I found Direct Mode to be much slower than using the Cached Mode with these SPI SRAM chips.
Furthermore, given the Sequential Access Mode feature of these SPI SRAMs, I wouldn't be surprised if Cached Mode would beat the Parallel multiplexed/latched arrangement on data throughput.
In my case I can't spare the pins to go with separate Address and Data lines, so the Quad Mode SPI SRAM operating in Cached Mode was a reasonable compromise.
Sounds good. I'll take you up on this offer at the appropriate time.
I bought a new USB Project Board from Parallax and decided to rearrange the XMM Memory and other components into a cleaner layout on this new board instead of the rats nest I have on my existing board.
As I await delivery of the ordered parts, I've moved on to writing various aspects of my Main application code...
… While keeping a close eye on the P2 testing and troubleshooting issues...
I finally modified my new Parallax USB Project Board with the XMM SRAM chips and an EEPROM.
The result is nothing like that clean and slick XMM memory board for the P2 designed by Von and posted by Chip on the P2 forum today, but it's good enough for testing
Here's the Top View:
This side uses "jumpers" to connect various "tracing" junctions on the other side of the board, as this was clearly a two-sided wiring job.
I used the breadboard as an insulator to keep these "jumpers" from accidentally shorting out anything on the top side. Plus the breadboard gives it an interesting if not quaint look.
The two chips on the left side of the breadboard are the ISSI 65WVS5128GBLL 512KB X 8 SPI SRAM chips. That single chip toward the center is the Atmel AT24CM02 256KB EEPROM chip.
The resistors you see are pullups for the SRAM CLK and CS, and the SDA and SCL for the EEPROM.
If you look closely you can see that I removed the 64KB EEPROM from the USB Board.
Parallax might be happy to know that this 256KB EEPROM does work with the Propeller. I'm able to store my CMM programs on it and the Propeller does load and execute the code upon startup. Seeing that it does work is a big relief.
Now here's Underside:
This side I used "tracing" to connect the components together by directly soldering copper wires to the various donut holes.
Regarding those 2 SRAM chips: I shamelessly ripped off Rayman's Rampage2 idea but deleted the Flash chips as I want my code to be stored on the EEPROM and execute from there upon bootup.
Each SRAM transfers a single nibble per read/write clock cycle, but by combining these nibbles onto the 8-bit bus one effectively transfers a single byte per clock cycle.
There is a noticeable speed difference when running XMM programs using this technique compared to the single nibble transfer when using only one SRAM like on my previous USB Project Board.
I wrote the CUSTOM_XMM driver (attached) to take advantage of this byte transfer arrangement. As long as the caching cog is transferring an even number of bytes at all times, then there shouldn't be any problems.
That being said, let's move on to running a program. For this test, I again used the MenuTest program (posted previously on this forum). In this case I configured it to run in CMM Mode.
I compiled the program and here's the build results:
I then used the Download To EEPROM command under Tools in Code::Blocks:
No problems there. I then ran the program, went through the Menu Screens, chose the Fibonacci Screen, and got this:
Very good. Working fine.
I then reconfigured Catalina to compile this using the SMALL XMM memory model with 4K cache. Keep in mind that build_utilities was already configured for this memory model.
Initially, I didn't select the EEPROM loader under Build Options. Here's the compile results:
So it compiled fine. Then, just as an experiment, I then attempted to Download To EEPROM and got this:
OK, so it failed. I expected that.
I then tried Download To XMM RAM And Interact. I went through the Menus and again selected the Fibonacci Screen. Here's how it looked:
Notice the screen update speed difference between XMM (1.6702 secs) versus CMM (1.0664). Not lightning fast, but acceptable for my purposes.
Then, I went back, modified the Build Options to include the EEPROM loader, recompiled, and got this:
Great, it compiled. Then, I attempted the Download To EEPROM again and got this:
Alright, it also failed. I also noticed that when using the EEPROM loader option, the Download To XMM RAM And Interact no longer works.
I know I'm doing something wrong here because it should be able to store my code in the EEPROM as it's much smaller than the 128KB limit the EEPROM loader supports. But I'm having a mental block and don't know what I should try next.
I would welcome your thoughts and suggestions on this. The hardware appears to be working but somewhere along the line I'm not configuring it correctly to store the XMM code in EEPROM.
The "Download to EEPROM" menu item only works for normal programs (i.e. size<= 32kb), not XMM programs. It executes a command like:
However, the "Download to XMM RAM and Interact" menu item is not what you want either - it uses the XMM loader, not the EEPROM loader. It actually executes a command like:
What you want is to download an XMM program to EEPROM (not XMM RAM) which requires that you build your program with -C EEPROM (which includes the code that loads your program from the EEPROM to XMM RAM **), but then use a command to program the EEPROM like:
But I don't have a preconfigured Code::Blocks menu item for that. My bad
You have a few options:
1. Use the command line.
2. Edit the "Download to XMM RAM and Interact" menu item (this is pretty easy to do in Code::Blocks - see "Tool->Configure Tools")
3. Add another "Download XMM to EEPROM and Interact" menu item (ditto).
I'd suggest you try (1) first, to make sure this solves the problem. Then either (2) or (3) for convenience.
Ross.
** I used to have code that would execute XMM SMALL programs directly from the EEPROM, instead of first loading them to XMM RAM, but it seems to have gotten lost somewhere along the line. I was sure it was in one of the very last of the Catalina P1 releases, but I have tried to find it and cannot. It may have been in a release that never actually got issued. It was just an implementation of the XMM API that read code direct from EEPROM (above the first 32kb) instead of from SRAM or FLASH. It wasn't particularly useful since it was generally slower than executing from XMM RAM and it could only be used for SMALL programs, but for completeness I may re-write it one day.
OK, for this test I will try the Command Line option since it's the easiest and quickest.
But first, making sure the EEPROM loader is included as part of the Build Options, and then compiling I get this:
It compiled the MenuTest program as an XMM SMALL with 4K Cache and included the EEPROM loader. So far, so good.
Next, I invoked a Command Prompt menu, made sure it was in the correct MenuTest directory, then did this:
Oops. It says it can't find the Secondary Loader.
Maybe the EEPROM loader wasn't included even though it said it was?
Or maybe the EEPROM loader won't work with the 256KB EEPROM?
I know for a fact Catalina can and does store CMM programs to this 256KB EEPROM without a problem because I've done it many times.
I also know that the CMM program was stored correctly in the 256KB EEPROM because it loads and executes correctly upon bootup.
Maybe the EEPROM loader has a problem accessing the EEPROM beyond 32KB, although just glancing at it the loader shouldn't have any problems at all accessing up to 64KB.
Let's take a quick look at three EEPROMs currently on the market: 64KB, 128KB, and 256KB.
For the 24LC512 EEPROM (64KB), the command/address scheme is this: Where the A2, A1, A0 in the Control Byte are hardware select lines allowing up to 8 of these EEPROMS to be placed on the I2C bus.
For an AT24CM01 (128KB) EEPROM, which the EEPROM Loader should support without modifications, the command/address scheme is this: Here the A2 and A1 in the Control Byte are hardware select lines allowing a maximum of 4 of these EEPROMs to be placed on the I2C bus. The A0 in the 24LC512 Command Byte has been replaced with address line A16 in the AT24CM01.
Finally, for the AT24CM02 (256KB) EEPROM the command/address scheme is this: Here the A2 in the Control Byte is the only hardware select line allowing only 2 of these EEPROMS to be placed on the I2C bus. The Command Byte A1 and A0 in the 24LC512 has been replaced with actual address lines A17 and A16 in the AT24CM02.
So if Industry ever develops a 512KB EEPROM, then that final A2 in the Command Byte will be replaced with address line A18, with a resulting downside that only a single device can be placed on the I2C bus. But for the Prop1 board that doesn't matter because only a single EEPROM is on the I2C bus as it is.
Anyway, the MenuTest program, including its Loader, checks in at less than 64KB, so it seems to me it should have been stored within the 256KB EEPROM without a problem since the A2, A17, and A16 values within the Control Byte should all be Zeros.
Thoughts?
Odd. The secondary loader is just the EEPROM.binary program (the primary loader is the one built into the Propeller). Even if the code doesn't load or run correctly, the secondary loader should be correctly detected by payload.
Here is an example of what I see when I use it:
I suspect that the EEPROM loader is failing as soon as it tries to talk to the EEPROM. Can you try your payload command with a -d option and post the output? That may tell us.
I'm getting ready to call it a night but I ran the Loader with the -d option.
Here is the result:
I don't know what the 0xfe response means from the initial Propeller Loader, but I assume it's correct?
Then it says it's having a Sync problem with the Secondary EEPROM Loader.
I don't remember if it was a Sync Error that I got last month while attempting to use the Flash Loader, but I do know it was unsuccessful because the Flash chip didn't support all of the commands needed to properly implement the Flash API functions.
In fact, that Flash problem prompted me to pursue the EEPROM route and dispense with the Flash chip completely.
On a related note, I've never had a problem with the XMM SRAM Loader as it worked every time I tried it. I use this all the time when testing and debugging my XMM code.
So getting back to the unanswered question with the EEPROM Loader: What is causing the Sync Error?
Thanks. The sync error is misleading. Here is the important bit:
Here is what I get in similar circumstances:
The sync error is because payload is trying to send a page of data to be programmed into EEPROM (it knows the program is intended for the EEPROM), but the EEPROM.binary program (which we just loaded, and which is supposed to accept the page and then program it) is apparently locking up and not sending back a response. So in this case, the message "No Secondary Loader found on any port" is a little misleading - it just means no working secondary loader was found.
This is what I thought - but I wanted to confirm it before I started digging. I need to figure out why the EEPROM loader is not responding. I need to have a look at the code, and maybe add some diagnostics. Most likely, the chip is just not responding to the commands being sent in the way the program expects. I will also have to look at the EEPROM chip specs. This may take some time - it's been years since I looked at that code.
I'll keep you posted, but if you have something else to get on with in the meantime, I'd suggest you do so.
Ross.