Definitely always runs successfully with the SD card inserted
Fails about 3/4 of executions with the SD card removed
But, I've gotten up to 15 consecutive successful executions with the SD card removed. I tried unplugging the QuickStart between sets of test runs and occasionally I get a run of successes, only to return to failure when I power-down and back up by unplugging USB, waiting 5 seconds and plugging back in.
Do we really know if the problem is a bad write or could it be just a bad read of what is actually "good" data? I'll start some debugging on that premiss.
dgately
I'm not sure if it is a bad read or write but I saw something odd when I was running only the SRAM test. Some of the wrong data that was displayed in the expected/found output looked like it might have come from the flash. I'll have to check to see if the flash read command is similar to the SRAM read command. Odd that the flash would output data when only the SRAM CS is asserted. Again, it might be some bug in my code. I'll look into it more tonight after work. Thanks for helping to test this!
For me it makes no difference if SD card is inserted or not. Test always fails. Sometimes the first read fails, sometimes the 32nd and then each following read. Here's the output of one of the runs (with sd card inserted)...
C:\Users\Christian\Documents\SimpleIDE\MemoryCardTest\CacheTestSD_Init>propeller
-load cachetest.elf -r -t -b QS-HIB-PMC
Propeller Version 1 on COM3
Loading cachetest.elf to hub memory
12400 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
mbox 00003070
cache 0000307c
buf 0000527c
Big RAM test
Start value 20001232
Filling RAM
Checking RAM
20000020: expected 2000123a, found 0030df20
20000024: expected 2000123b, found 0030de20
20000030: expected 2000123e, found 81bf3e3e
20000034: expected 2000123f, found 699dcd77
20000038: expected 20001240, found ed3f5a97
2000003c: expected 20001241, found ddee9f75
20000040: expected 20001242, found bf7712df
20000044: expected 20001243, found 663fb2df
20000048: expected 20001244, found 70f69afd
2000004c: expected 20001245, found f3fcbbbd
David, do you know which read method is used for the flash? In the Flash datasheet I read that after sending the address some dummy clock impulses need to be present before the FlashRam returns the data.
I don't know if that could be the reason why reading flash sometimes fails...?
David, do you know which read method is used for the flash? In the Flash datasheet I read that after sending the address some dummy clock impulses need to be present before the FlashRam returns the data.
I don't know if that could be the reason why reading flash sometimes fails...?
Christian
This is the code that handles Winbond flash reads. Notice the zero being sent after the command. Those are the dummy bits.
start_read
mov cmd, vmaddr
and cmd, offset_bits
or cmd, winbond_read
mov bytes, #4
call #winbond_start_quad_spi_cmd
mov data, #0
call #sqiSendByte
andn dira, sio_mask
start_read_ret
ret
winbond_read long $e3000000 ' flash read command
I'll write a litte c program which fills the flashRam and checks the data where I can adjust the clock frequency. Maybe that helps to understand why flash and sram always fail on my side.
Don't know if that helps but I hope
I'll write a litte c program which fills the flashRam and checks the data where I can adjust the clock frequency. Maybe that helps to understand why flash and sram always fail on my side.
Don't know if that helps but I hope
It might help. I remember having some trouble getting quad-spi working when I just put a chip on the breadboard of a PropBOE. I think my problem was missing pull-up resistors though. The PMC certainly has those.
Sorry, I spent quite a bit of time playing with the driver tonight but didn't really make any headway. I'm afraid I'm out of ideas. i tried adding some NOP instructions to slow down the SPI commands but I ran out of COG memory. This driver is already very close to filling COG RAM so it's difficult to add much debugging code. I will try again if I come up with any new ideas.
I know these situations when you can't figure out what's causing the problem or where the bug could be and then some time later it makes "bing" and you know why it didn't work. Thanks again for spending a lot of time with my problem. It will take some time for me to do a c implementation of a flash/ram accessor class just to test my setup but it will be done in the next days I think.
You said some messages above that you don't have any issues with Rays RamPage modules. Maybe the design of the Propeller Memory card itself is the issue not really the driver if the same driver works for the other product but not for this one...
I've just fixed a bug that was pointed out to me by kuroneko but unfortunately that doesn't really improve things any. I'm beginning to think that sharing pins between the SD card and other SPI devices is a bad idea. The SD card isn't even a SPI device on power up. However, even that doesn't explain all of the problems. I even have trouble if I just set the SD CS pin (pin 4) high without actually sending any data to the SD card.
Do you know how the cache handles updating bytes in the flash memory? As far as I can see the flash has to be erased before it can be rewritten and erasing can only be done in 4k blocks and greater or the whole chip can be erased.
When running a program in xmmc-single mode, code and data are in flash. If a variable is changed, does the "wrapper code", which uses the cache to get data from flash, first read a whole block to hub ram, updates the variable in hub ram, then erases the block and writes the block to flash or is there a more performant way to do it?
Also are there any documents describing how to write such drivers for the propeller especially describing the interface of the mailbox which is used by all the cache drivers or better a document describing how it is implemented, that code is fetched from external memory into hub, executed and then new code is fetched again and so on.
As far as I can understand, the cache driver is only the part which handles reading/writing to external memory. So there must be some host code which uses the different cache drivers to handle all that stuff. Are there any howto's or documents, interface definitions available?
Do you know how the cache handles updating bytes in the flash memory? As far as I can see the flash has to be erased before it can be rewritten and erasing can only be done in 4k blocks and greater or the whole chip can be erased.
When running a program in xmmc-single mode, code and data are in flash. If a variable is changed, does the "wrapper code", which uses the cache to get data from flash, first read a whole block to hub ram, updates the variable in hub ram, then erases the block and writes the block to flash or is there a more performant way to do it?
Also are there any documents describing how to write such drivers for the propeller especially describing the interface of the mailbox which is used by all the cache drivers or better a document describing how it is implemented, that code is fetched from external memory into hub, executed and then new code is fetched again and so on.
As far as I can understand, the cache driver is only the part which handles reading/writing to external memory. So there must be some host code which uses the different cache drivers to handle all that stuff. Are there any howto's or documents, interface definitions available?
The xmm-single memory model can not be used with flash. It can only be used with external RAM. No writes are allowed to flash other than when the program is initially loaded and then we erase as many 4K blocks as needed to load the program. Writes to flash in your program are treated as NOPs.
Ah, ok, I see. Regarding the other questions about documents, are there any available to the public?
The drivers, like the one we've been trying to debug here, all include "cache_interface.spin" which defines the interface to the driver used by the XMM kernel and "cache_common.spin" which includes common code used by all drivers to receive requests through the mailbox. It also does all of the cache tag handling hit/miss processing etc. The only thing you need to write are a handful of functions that are described at the end of the "cache_common.spin" file. Also, you should know that I'm in the process of changing this interface entirely to match a driver interface that Chip defined for his SDRAM driver for the Propeller 2. That is a work in progress and probably won't be available right away but it moves all of the cache tag handling into the XMM kernel so that the only operations required of the driver are read/write blocks of external memory.
Because the overall implementation is in spin, is it possible to write the driver, which does the memory access, in C or is such a mixture impossible.
But maybe I have to try to get a simple c program working which accesses flash and sram before I have to think about such things
Because the overall implementation is in spin, is it possible to write the driver, which does the memory access, in C or is such a mixture impossible.
But maybe I have to try to get a simple c program working which accesses flash and sram before I have to think about such things
You could write a driver using the PropGCC COG mode (-mcog). You'd have to implement all of the cache tag handling yourself in that case. If you wait until the revised drivers are available this would be a lot easier since all your driver would have to do is read/write blocks (cache lines) of external memory.
By the way, I looked at the Parallax Spin test code and it looks like it's using SPI mode not QuadSPI mode like my driver uses.
Yes, I noticed that too, that the spin demo is just using SPI. What I'm going to do for now is just a simple program which erases flash und writes some data and reads it back with adjustable clock speed. I want to know if my breadboard setup makes the card unusable or if it really isn't working properly.
I want to go on with my pinball project where I am currently doing the schematics for the driver board which drives all the coils, leds, flashers and the dmd matrix.
I added support for the memory card there but if the card isn't working I have to use Rays with updated pin usages which needs to be reflected in the dirver board schematic. If I have to wait, the project is frozen up.
Do you have any timeline until the revised drivers are available?
Yes, I noticed that too, that the spin demo is just using SPI. What I'm going to do for now is just a simple program which erases flash und writes some data and reads it back with adjustable clock speed. I want to know if my breadboard setup makes the card unusable or if it really isn't working properly.
Actually, we have several other drivers you could try. For example, the winbond_sqi_flash_xcache driver only tries to use the flash chip, the sqi_sram_xcache driver only tries to use the SRAM chip, and there are spi versions of both of those as well.
I want to go on with my pinball project where I am currently doing the schematics for the driver board which drives all the coils, leds, flashers and the dmd matrix.
I added support for the memory card there but if the card isn't working I have to use Rays with updated pin usages which needs to be reflected in the dirver board schematic. If I have to wait, the project is frozen up.
Ray's board uses more pins since he doesn't share pins between SD and SPI. I guess that's what you mean by updating pin usage. His board nicely plugs into the expansion connector on the QuickStart board though. You don't need to do any manual wiring and you don't need the Parallax Human Interface Board in between.
Do you have any timeline until the revised drivers are available?
The driver changes are done but I have a bunch of loader changes I still need to make. Unfortunately, the loader knows a lot about how the external memory drivers work because it has to load the program using them.
Actually, we have several other drivers you could try. For example, the winbond_sqi_flash_xcache driver only tries to use the flash chip, the sqi_sram_xcache driver only tries to use the SRAM chip, and there are spi versions of both of those as well.
Oh, I didn't know that these can also be used, I will try them when I'm at home :thumb: Thanks for pointing that out!
Ray's board uses more pins since he doesn't share pins between SD and SPI. I guess that's what you mean by updating pin usage. His board nicely plugs into the expansion connector on the QuickStart board though. You don't need to do any manual wiring and you don't need the Parallax Human Interface Board in between.
Yes, sorry, thats what I meant. The RamPage modules has a different pin layout so I have to update my schematics. My plan is to use the quickstart board as is as the processor board. That board is connected via a ribbon cable to my driver board. The ribbon cable is connected to the quickstart header and the other side on header pins on the pinball driver board. There i route the different pins to shift registers, led drivers and also to a header where the memory board gets plugged in. If I use another memory board, I have to change the board layout.
The driver changes are done but I have a bunch of loader changes I still need to make. Unfortunately, the loader knows a lot about how the external memory drivers work because it has to load the program using them.
Ouh, sounds like there is a lot of work left for you to do which of course will take it's time.
Yes, sorry, thats what I meant. The RamPage modules has a different pin layout so I have to update my schematics. My plan is to use the quickstart board as is as the processor board. That board is connected via a ribbon cable to my driver board. The ribbon cable is connected to the quickstart header and the other side on header pins on the pinball driver board. There i route the different pins to shift registers, led drivers and also to a header where the memory board gets plugged in. If I use another memory board, I have to change the board layout.
I think Ray will sell you a RamPage2 board without the headers installed so you could use stacking heards and plug the RamPage2 directly into the QuickStart and then your ribbon cable into the stacking connector. Would that work? Then you avoid the long wires that might interfere with the operation of the memory chips.
I think Ray will sell you a RamPage2 board without the headers installed so you could use stacking heards and plug the RamPage2 directly into the QuickStart and then your ribbon cable into the stacking connector. Would that work? Then you avoid the long wires that might interfere with the operation of the memory chips.
Yes, thats a good idea to stack the boards and then put the connector on top of them.
But before I order a memory card from Ray I try to get the one I have to work. If everything fails I have to order one from Ray.
Yes, thats a good idea to stack the boards and then put the connector on top of them.
But before I order a memory card from Ray I try to get the one I have to work. If everything fails I have to order one from Ray.
Yes, I'm still looking for the bug in my PMC driver!
But if you do get to the point of ordering one of Ray's cards, you could also solder a downward facing female header in the spare header holes on the QuickStart and mount the RamPage2 underneath the QuickStart. Also, I have a special driver for the RamPage2 that uses all of the memory chips and can read/write 8 bits at a time instead of just 4.
Just had a look at Rays webpage. The RamPage2 card uses too many Prop pins. I'm really out of pins... That was the reason to try the Parallax Card because this card also supports SD cards by only using 8 Prop pins.
Maybe I could use the older RamPage1 card. 2Mb of flash is more than enough for code. But even then I have to use a 2nd prop which communicates with the master prop because I run out of pins.
The Prop2 would be the absolutely ideal solution, but not available until next year
Just had a look at Rays webpage. The RamPage2 card uses too many Prop pins. I'm really out of pins... That was the reason to try the Parallax Card because this card also supports SD cards by only using 8 Prop pins.
Maybe I could use the older RamPage1 card. 2Mb of flash is more than enough for code. But even then I have to use a 2nd prop which communicates with the master prop because I run out of pins.
The Prop2 would be the absolutely ideal solution, but not available until next year
Let's hope I can get the PMC bug fixed so you can use the board you already have. :-)
FYI, I just tried the spi_sram24_xcache driver and it seems to work although it only supports the SRAM and not the flash. However, the sqi_sram_xcache driver fails in the same way as the combined flash/SRAM driver fails. I guess I need to look over my QuadSPI code. In case you're interested in trying it on your setup I've attached a zip file with the cachetest program and the SPI SRAM driver.
Edit: The nice thing about the sqi_sram_xcache driver having the same bad behavior as the combined driver is that it is quite a bit simpler so MAY be easier to debug!
C:\Users\Christian\Documents\SimpleIDE\MemoryCardTest\CacheTest_SPI_SRAM>propell
er-load cachetest.elf -r -t -b QS-HIB-PMC
Propeller Version 1 on COM3
Loading cachetest.elf to hub memory
11688 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
mbox 00002da8
cache 00002db4
buf 00004fb4
Big RAM test
Start value 20003239
Filling RAM
Checking RAM
20000000: expected 20003239, found ffffffff
20000004: expected 2000323a, found ffffffff
20000008: expected 2000323b, found ffffffff
2000000c: expected 2000323c, found ffffffff
20000010: expected 2000323d, found ffffffff
20000014: expected 2000323e, found ffffffff
20000018: expected 2000323f, found ffffffff
2000001c: expected 20003240, found ffffffff
20000020: expected 20003241, found ffffffff
20000024: expected 20003242, found ffffffff
20000028: expected 20003243, found ffffffff
2000002c: expected 20003244, found ffffffff
20000030: expected 20003245, found ffffffff
20000034: expected 20003246, found ffffffff
20000038: expected 20003247, found ffffffff
2000003c: expected 20003248, found ffffffff
20000040: expected 20003249, found ffffffff
20000044: expected 2000324a, found ffffffff
20000048: expected 2000324b, found ffffffff
2000004c: expected 2000324c, found ffffffff
20000050: expected 2000324d, found ffffffff
20000054: expected 2000324e, found ffffffff
20000058: expected 2000324f, found ffffffff
2000005c: expected 20003250, found ffffffff
20000060: expected 20003251, found ffffffff
20000064: expected 20003252, found ffffffff
20000068: expected 20003253, found ffffffff
2000006c: expected 20003254, found ffffffff
20000070: expected 20003255, found ffffffff
20000074: expected 20003256, found ffffffff
20000078: expected 20003257, found ffffffff
2000007c: expected 20003258, found ffffffff
20000080: expected 20003259, found ffffffff
20000084: expected 2000325a, found ffffffff
20000088: expected 2000325b, found ffffffff
2000008c: expected 2000325c, found ffffffff
20000090: expected 2000325d, found ffffffff
20000094: expected 2000325e, found ffffffff
20000098: expected 2000325f, found ffffffff
2000009c: expected 20003260, found ffffffff
200000a0: expected 20003261, found ffffffff
200000a4: expected 20003262, found ffffffff
200000a8: expected 20003263, found ffffffff
200000ac: expected 20003264, found ffffffff
200000b0: expected 20003265, found ffffffff
200000b4: expected 20003266, found ffffffff
200000b8: expected 20003267, found ffffffff
200000bc: expected 20003268, found ffffffff
200000c0: expected 20003269, found ffffffff
200000c4: expected 2000326a, found ffffffff
200000c8: expected 2000326b, found ffffffff
200000cc: expected 2000326c, found ffffffff
200000d0: expected 2000326d, found ffffffff
200000d4: expected 2000326e, found ffffffff
200000d8: expected 2000326f, found ffffffff
200000dc: expected 20003270, found ffffffff
200000e0: expected 20003271, found ffffffff
200000e4: expected 20003272, found ffffffff
200000e8: expected 20003273, found ffffffff
200000ec: expected 20003274, found ffffffff
200000f0: expected 20003275, found ffffffff
200000f4: expected 20003276, found ffffffff
200000f8: expected 20003277, found ffffffff
200000fc: expected 20003278, found ffffffff
20000100: expected 20003279, found ffffffff
20000104: expected 2000327a, found ffffffff
20000108: expected 2000327b, found ffffffff
2000010c: expected 2000327c, found ffffffff
20000110: expected 2000327d, found ffffffff
20000114: expected 2000327e, found ffffffff
20000118: expected 2000327f, found ffffffff
2000011c: expected 20003280, found ffffffff
20000120: expected 20003281, found ffffffff
20000124: expected 20003282, found ffffffff
20000128: expected 20003283, found ffffffff
2000012c: expected 20003284, found ffffffff
20000130: expected 20003285, found ffffffff
20000134: expected 20003286, found ffffffff
20000138: expected 20003287, found ffffffff
2000013c: expected 20003288, found ffffffff
20000140: expected 20003289, found ffffffff
20000144: expected 2000328a, found ffffffff
20000148: expected 2000328b, found ffffffff
2000014c: expected 2000328c, found ffffffff
20000150: expected 2000328d, found ffffffff
20000154: expected 2000328e, found ffffffff
20000158: expected 2000328f, found ffffffff
Does the driver use the same pins? Because it is SPI it should use the prop pins 0&1 for data in/out and 7 for clk, is that correct?
Hmmm... I wish I knew how to solve the problem with running the SRAM in QuadSPI mode on the PMC. The same driver works fine on my RamPage2 board and this time I'm only using a driver that supports the SRAM and both the PMC and the RamPage2 use the same SRAM chip. What could be different about the PMC that would make it fail?
David Carrier: Any idea what I might be doing wrong?
This latest cachetest.elf is the only "cachetest" binary I've seen work on both of my boards with or without SD Card inserted.
@trancefreak, getting all ffffffff back suggests that one of your connections (P0, P1 or other) is defective some way. Can you check if the wires are good?
Writing/Reading to flash works with the demo spin code but sram never did. The spin demo also returns always FFFF when reading from sram.
So I think that it isn't a connection issue because flash works (with the spin demo).
I'm now in the office but when I am at home I'll do a test with my old oscilloscope and check if there is a nice square signal on pins 0-7 where I normally connect the PMC.
If there is one I'm sure that my sram part on the PMC is not working.
Comments
David, do you know which read method is used for the flash? In the Flash datasheet I read that after sending the address some dummy clock impulses need to be present before the FlashRam returns the data.
I don't know if that could be the reason why reading flash sometimes fails...?
Christian
start_read mov cmd, vmaddr and cmd, offset_bits or cmd, winbond_read mov bytes, #4 call #winbond_start_quad_spi_cmd mov data, #0 call #sqiSendByte andn dira, sio_mask start_read_ret ret winbond_read long $e3000000 ' flash read commandDon't know if that helps but I hope
I know these situations when you can't figure out what's causing the problem or where the bug could be and then some time later it makes "bing" and you know why it didn't work. Thanks again for spending a lot of time with my problem. It will take some time for me to do a c implementation of a flash/ram accessor class just to test my setup but it will be done in the next days I think.
You said some messages above that you don't have any issues with Rays RamPage modules. Maybe the design of the Propeller Memory card itself is the issue not really the driver if the same driver works for the other product but not for this one...
Regards,
Christian
Do you know how the cache handles updating bytes in the flash memory? As far as I can see the flash has to be erased before it can be rewritten and erasing can only be done in 4k blocks and greater or the whole chip can be erased.
When running a program in xmmc-single mode, code and data are in flash. If a variable is changed, does the "wrapper code", which uses the cache to get data from flash, first read a whole block to hub ram, updates the variable in hub ram, then erases the block and writes the block to flash or is there a more performant way to do it?
Also are there any documents describing how to write such drivers for the propeller especially describing the interface of the mailbox which is used by all the cache drivers or better a document describing how it is implemented, that code is fetched from external memory into hub, executed and then new code is fetched again and so on.
As far as I can understand, the cache driver is only the part which handles reading/writing to external memory. So there must be some host code which uses the different cache drivers to handle all that stuff. Are there any howto's or documents, interface definitions available?
But maybe I have to try to get a simple c program working which accesses flash and sram before I have to think about such things
By the way, I looked at the Parallax Spin test code and it looks like it's using SPI mode not QuadSPI mode like my driver uses.
I want to go on with my pinball project where I am currently doing the schematics for the driver board which drives all the coils, leds, flashers and the dmd matrix.
I added support for the memory card there but if the card isn't working I have to use Rays with updated pin usages which needs to be reflected in the dirver board schematic. If I have to wait, the project is frozen up.
Do you have any timeline until the revised drivers are available?
Yes, sorry, thats what I meant. The RamPage modules has a different pin layout so I have to update my schematics. My plan is to use the quickstart board as is as the processor board. That board is connected via a ribbon cable to my driver board. The ribbon cable is connected to the quickstart header and the other side on header pins on the pinball driver board. There i route the different pins to shift registers, led drivers and also to a header where the memory board gets plugged in. If I use another memory board, I have to change the board layout.
Ouh, sounds like there is a lot of work left for you to do which of course will take it's time.
But before I order a memory card from Ray I try to get the one I have to work. If everything fails I have to order one from Ray.
But if you do get to the point of ordering one of Ray's cards, you could also solder a downward facing female header in the spare header holes on the QuickStart and mount the RamPage2 underneath the QuickStart. Also, I have a special driver for the RamPage2 that uses all of the memory chips and can read/write 8 bits at a time instead of just 4.
Maybe I could use the older RamPage1 card. 2Mb of flash is more than enough for code. But even then I have to use a 2nd prop which communicates with the master prop because I run out of pins.
The Prop2 would be the absolutely ideal solution, but not available until next year
Thanks David!
cachetest-spi-sram.zip
Edit: The nice thing about the sqi_sram_xcache driver having the same bad behavior as the combined driver is that it is quite a bit simpler so MAY be easier to debug!
If I execute the test I get the following output:
Does the driver use the same pins? Because it is SPI it should use the prop pins 0&1 for data in/out and 7 for clk, is that correct?
That is, MOSI=0, MISO=1, CLK=7, SRAM-CS=6.
This driver doesn't do any SD initialization so you'll have to run it with no SD card inserted.
David Carrier: Any idea what I might be doing wrong?
@trancefreak, getting all ffffffff back suggests that one of your connections (P0, P1 or other) is defective some way. Can you check if the wires are good?
Writing/Reading to flash works with the demo spin code but sram never did. The spin demo also returns always FFFF when reading from sram.
So I think that it isn't a connection issue because flash works (with the spin demo).
I'm now in the office but when I am at home I'll do a test with my old oscilloscope and check if there is a nice square signal on pins 0-7 where I normally connect the PMC.
If there is one I'm sure that my sram part on the PMC is not working.
I'll keep you posted.
Christian