The QE bit is set by default for the winbond chip so you directly can switch to QPI mode by sending 38h IIRC.
To check if the winbond chip is already in QPI mode I read the JEDEC ID via SPI. If it doesn't return EFh (because in QPI mode, sending commands via SPI doesn't work), I assume that QPI mode is on. I didn't find a better way because if the chip is already in SPI mode then using QPI (all 4 lines switched to output) could do some damage because if the chip is in SPI mode DO is switched to output.
But maybe there is a better way ;-)
That's odd. The data sheet that I downloaded from the Winbond site said that the factory default for the QE bit is 0.
Just had a quick look at the spiSend / sqiSend methods you use.
sqiSendByte
mov bits, data
ror bits, #4
rol bits, sio_shift
and bits, sio_mask
andn outa, sio_mask
or outa, bits
or outa, sck_mask
andn outa, sck_mask
rol data, sio_shift
and data, sio_mask
andn outa, sio_mask
or outa, data
or outa, sck_mask
andn outa, sck_mask <= clk is set to low after sending the byte
sqiSendByte_ret
ret
I haven't had a look at the SRAM datasheet but the winbond datasheet says, that after clocking in the command/address and the dummy clocks the
chip switches IO0-IO3 immediately to output on the falling edge of the clock. The spiSend and sqiSend both pull clk always low at the end of sending
the bytes. And then you switch IO0 - IO3 to input.
Maybe this could cause issues because there could be a small time overlap where IO1 is switched to output and the ram chip already switched the io lines to output.
I think you could try it as follows:
Leave the clk high after sending the last command byte/dummy byte, switch the IO lines to input and then set clk to low and continue reading the data.
I know it's hard to understand what I mean because I'm not a native english speaking person, but just let me know if you didn't understand what I mean.
I think you could try it as follows:
Leave the clk high after sending the last command byte/dummy byte, switch the IO lines to input and then set clk to low and continue reading the data.
That is a very good suggestion. In fact, I'm pretty sure I modified one of my drivers to do that a long time ago. That change must not have made it into this driver. I'll try that as soon as I have a few free moments. Thanks for looking over the code and noticing that!!
No problem. Let's hope that this was causing the problems
I did a quick test and this change didn't affect the behavior of my driver. I'm now wondering if there is any chance that the SRAM chip is dead because the error you mentioned might have resulting in both the Propeller and the SRAM chip driving the same data line at the same time to different states. Wouldn't that have resulted in a short?
Oddly, I just removed my PMC board from my QS+HIB stack and plugged it into the breadboard of an ActivityBoard and wired it to P0-P7 and it seems to work fine. It runs the entire suite of PMC tests including flash, SRAM, and cache test with no errors.
Edit: This is with no SD card inserted. I haven't tried it with the SD card.
Edit2: Is it possible that the touch buttons that are also connected to P0-P7 on the QuickStart board could interfere with the memory chips?
Edit3: I just tried it with an SD card inserted and it works that way as well.
Edit4: Finally, I've attached the copy of cachetest.elf that I'm running in case you want to try it yourself.
I had time to do a test with the attached cachetest. Flash test #1 passes, but inverted flash test fails every time.
SRAM test fails immediately. The first read back value is wrong as each following.
So maybe my SRAM chip is defect but I hope not! I'll do some tests later in the evening when the kids are in bed.
I had time to do a test with the attached cachetest. Flash test #1 passes, but inverted flash test fails every time.
SRAM test fails immediately. The first read back value is wrong as each following.
So maybe my SRAM chip is defect but I hope not! I'll do some tests later in the evening when the kids are in bed.
Maybe but then why would inverted flash fail on your board? I guess I could try one additional test of attaching using a breadboard to a QuickStart board instead of the ActivityBoard. I didn't have a handy setup for that but I can do it later.
Edit: This is with no SD card inserted. I haven't tried it with the SD card.
Edit2: Is it possible that the touch buttons that are also connected to P0-P7 on the QuickStart board could interfere with the memory chips?
Edit3: I just tried it with an SD card inserted and it works that way as well.
Edit4: Finally, I've attached the copy of cachetest.elf that I'm running in case you want to try it yourself.
On my QS+HIB, all tests run successfully (with SD card, without SD card), until I touch one or more of the touch buttons! Then, all hell breaks loose
From the time I touch any of the buttons until I unplug/replug in the board or provide additional ground between the QS and the HIB, I get failures while it checks the RAM. I currently have two hex standoffs between the HIB and the QS, but they are bolted to the HIB by screws. They are not at this time attached well to the QS as they just sit on top of the screw-hole grounding points on the QS. When I press the HIB down to make sure there is good contact between the standoffs and the QS, the RAM test works successfully. I'll put longer screws through the standoffs to make sure there is always good contact.
Should this be a problem? I mean, there is a ground connection between the QS and the HIB via the QS connector, right? Is it that I'm building-up a static charge around the touch buttons that just doesn't leave until I give the boards better grounding, that is "fixing" the problem?
I tried plugging my PMC into a breadboard and connecting it to a QuickStart and the flash still works but the SRAM now fails in the same way as it did with the HIB inserted in between the QS and the PMC.
I have prepared a very, very simple sram test for me which just writes 4 bytes and that is failing, too.
Something strange is going on. I definitely can't write byte values greater 0xef to the sram chip. 0xef works, 0xf0 never works?????
Also not each byte is correct... Sometimes all 4 are correct (if value <= 0xef), sometimes only byte 1 and 4 are correct, 2 and 3 are false.
I've added a configurable delay when spi'ing out data so that between clock low => high => low are delays. I tried it with 100ms and greater, but that didn't fix my issues.
So I don't think that my setup fails due to high frequency and cable to breadboard issues.
I believe my SRAM chip is definitely defect.
David, please would you be so kind to test the program I've attached just to get sure it works. It should output:
aa
bb
cc
ff
Interesting why it failed with the QuickStart but succeeded with the ActivityBoard.
What I found out on my side is:
When I try to write a value > 0xef the value is not written, looks like it is completely ignored. Because when I read back the values, I get the previously stored values instead the newly sent one > 0xef.
Example:
I send these byte values to the SRAM:
aa
bb
cc
dd
Then (without disconnecting the board from my laptop so that the SRAM is connected to Vdd and keeps the values), if I store the same values but the last one being ff:
dd
ab
dc
ff
and I read back the values I get back
dd,
ab
dc
dd (The value I previously stored at the same SRAM address).
Thats reproducable every time I do this.
When I store values <= 0xef it works 90% of the time.
That's really strange
Maybe it's generally not a good idea to connect such memory cards via pin headers or cables. The best would be having a propeller board with flash and sram included.
Is there any board out there without any other stuff like vga, audio or other connectors? Just flash and sram and the rest of the pins routed to a header?
Maybe it's generally not a good idea to connect such memory cards via pin headers or cables. The best would be having a propeller board with flash and sram included.
Is there any board out there without any other stuff like vga, audio or other connectors? Just flash and sram and the rest of the pins routed to a header?
Yes, I think having the flash and SRAM on the same board as the Propeller chip is probably the way to go. As you probably know, Parallax has the C3 that has both a flash and a couple of SRAM chips on it but they aren't quad chips. Also, the Propeller DNA board is nice:
Thanks both links, they are great. The link to http://mghdesigns.com/wiki/dna:start also includes schematic and pcb layout, thats really helpful.
I think I will use this as an idea. Thanks!
Maybe it's generally not a good idea to connect such memory cards via pin headers or cables.
I'm not convinced that this is just a problem with connecting a memory card through a header. As I said earlier, both your test program and my SRAM driver work with the PMC plugged into the breadboard of an ActivityBoard. I'm wondering if there is some issue on the QuickStart with sharing pins with the touch buttons. Have you tried running your test program with the PMC wired to P8--P15?
I'm not convinced that this is just a problem with connecting a memory card through a header. As I said earlier, both your test program and my SRAM driver work with the PMC plugged into the breadboard of an ActivityBoard. I'm wondering if there is some issue on the QuickStart with sharing pins with the touch buttons. Have you tried running your test program with the PMC wired to P8--P15?
I just tried to do this myself with my QuickStart + breadboard setup but I find I can't rebuild your test program because it requires more than just the .c file that you sent me.
Hi David, sorry, wasn't at the laptop.
I've attached the complete SimpleIDE project with all sources. I'll also try it with different ports by myself tomorrow, now it's really late here ;-)
Just tried it with pins 8 and up but it still doesn't work. Can't store 0xff as value. It still gets "ignored". So changing the pins didn't solve my problem.
Just tried it with pins 8 and up but it still doesn't work. Can't store 0xff as value. It still gets "ignored". So changing the pins didn't solve my problem.
That's very odd. I wonder why it works on the ActivityBoard? I'm in the process of making a stripped down SRAM driver that is all in a single .spin file to make it easier to diagnose problems. If I can get that working, I'll merge it with the flash code to make a PMC-specific driver.
Maybe my test setup isn't really meaningful. I always had problems with sram from the beginning. The original Parallax Spin demo also never worked. It really can be that something is broken on my PMC board. So I think if it works for you on a breadboard with wires then the code is working. For me I think I have a defect card because it absolutely makes no sense why 0xff is never stored but other values can be stored correctly (but also only 90% of the time, 10% it fails).
Maybe my test setup isn't really meaningful. I always had problems with sram from the beginning. The original Parallax Spin demo also never worked. It really can be that something is broken on my PMC board. So I think if it works for you on a breadboard with wires then the code is working. For me I think I have a defect card because it absolutely makes no sense why 0xff is never stored but other values can be stored correctly (but also only 90% of the time, 10% it fails).
Except that I had a similar problem with my PMC board when it was connected to the QuickStart but not when it was plugged into my ActivityBoard.
Okay, here is a merged and simpler version of my SQI SRAM driver. It works on the ActivityBoard but not on the QuickStart. Also, it has the modification that you suggested to hold the SCK line high while reversing the direction of the IO0-3 bus. This didn't work on the QuickStart even when I moved it to pins 8-15. Can you see what I'm doing wrong here? I asked David Carrier to visit this thread to give us advice so maybe he'll be able to clear this up.
Edit: I tried this driver using P8-P15 on a QuickStart and that didn't work either. This seems very strange to me because looking at the QuickStart schematic, it looks like there is nothing connected to P8-P15. They just go to the header into which I plugged the wires that connected to the PMC on the breadboard. Something very odd happening here. I would welcome anyone looking over the code and offering advice as to how to fix this!
This is very bizarre. I just tried plugging a 23LC1024 SRAM chip into U12 on a DNA board and the test works fine on that board as well. It just seems to fail on QuickStart.
Edit: It works on RamPage2 as well. So, it works on DNA, RamPage2, PMC+ActivityBoard, but not PMC+QuickStart.
Because all boards use the same microcontroller, the only thing which comes to my mind which could be different is how the pins are routed from the controller
to the header. I know for high frequency applications you should not route the traces in parallel and so on. Maybe the quickstart has a different layout. But that would only
apply for higher frequencies. I attached the full SimpleIDE project of my minimal test program some messages earlier. Maybe you could enable the delay method to check, if byte output is
correct when there is a delay.
But I tried it with 100ms and above but that didn't work out, same behavior as with "full speed".
So if lowering the speed does not work, I have no other idea, what could cause the PMC + QuickStart to fail.
The quickstart works fine with shift out registers. For my pinball project I have attached a shift out register which I access via a cogc program in "full speed" and that works without any problems. The communication is also SPI like.
So I don't know, why the PMC does not like the QuickStart. Maybe some of the hardware guys from Parallax could enlighten us.
I haven't been following all the details on this thread, but from what I read it looks like the problem only happens on the QuickStart board, correct? The Propeller Project Board USB contains a QuickStart header, and there is a known problem with the XI line and VGA on that board. Maybe the QuickStart board has a similar problem with the XI line. From what I understand on the Project Board USB is that there is some crosstalk between the XI trace running from the crystal to the header. The fix for the Project Board is to cut this trace near the crystal by drilling it out.
Is there an image of the QS layout available that would show which lines run adjacent to the XI trace? Maybe if these I/O pins were avoided it would resolve the problem.
Comments
sqiSendByte mov bits, data ror bits, #4 rol bits, sio_shift and bits, sio_mask andn outa, sio_mask or outa, bits or outa, sck_mask andn outa, sck_mask rol data, sio_shift and data, sio_mask andn outa, sio_mask or outa, data or outa, sck_mask andn outa, sck_mask <= clk is set to low after sending the byte sqiSendByte_ret retI haven't had a look at the SRAM datasheet but the winbond datasheet says, that after clocking in the command/address and the dummy clocks the
chip switches IO0-IO3 immediately to output on the falling edge of the clock. The spiSend and sqiSend both pull clk always low at the end of sending
the bytes. And then you switch IO0 - IO3 to input.
Maybe this could cause issues because there could be a small time overlap where IO1 is switched to output and the ram chip already switched the io lines to output.
I think you could try it as follows:
Leave the clk high after sending the last command byte/dummy byte, switch the IO lines to input and then set clk to low and continue reading the data.
I know it's hard to understand what I mean because I'm not a native english speaking person, but just let me know if you didn't understand what I mean.
Christian
Edit: This is with no SD card inserted. I haven't tried it with the SD card.
Edit2: Is it possible that the touch buttons that are also connected to P0-P7 on the QuickStart board could interfere with the memory chips?
Edit3: I just tried it with an SD card inserted and it works that way as well.
Edit4: Finally, I've attached the copy of cachetest.elf that I'm running in case you want to try it yourself.
cachetest.zip
I had time to do a test with the attached cachetest. Flash test #1 passes, but inverted flash test fails every time.
SRAM test fails immediately. The first read back value is wrong as each following.
So maybe my SRAM chip is defect but I hope not! I'll do some tests later in the evening when the kids are in bed.
On my QS+HIB, all tests run successfully (with SD card, without SD card), until I touch one or more of the touch buttons! Then, all hell breaks loose
From the time I touch any of the buttons until I unplug/replug in the board or provide additional ground between the QS and the HIB, I get failures while it checks the RAM. I currently have two hex standoffs between the HIB and the QS, but they are bolted to the HIB by screws. They are not at this time attached well to the QS as they just sit on top of the screw-hole grounding points on the QS. When I press the HIB down to make sure there is good contact between the standoffs and the QS, the RAM test works successfully. I'll put longer screws through the standoffs to make sure there is always good contact.
Should this be a problem? I mean, there is a ground connection between the QS and the HIB via the QS connector, right? Is it that I'm building-up a static charge around the touch buttons that just doesn't leave until I give the boards better grounding, that is "fixing" the problem?
Anywho, that's what I've found, so far.
dgately
Something strange is going on. I definitely can't write byte values greater 0xef to the sram chip. 0xef works, 0xf0 never works?????
Also not each byte is correct... Sometimes all 4 are correct (if value <= 0xef), sometimes only byte 1 and 4 are correct, 2 and 3 are false.
I've added a configurable delay when spi'ing out data so that between clock low => high => low are delays. I tried it with 100ms and greater, but that didn't fix my issues.
So I don't think that my setup fails due to high frequency and cable to breadboard issues.
I believe my SRAM chip is definitely defect.
David, please would you be so kind to test the program I've attached just to get sure it works. It should output:
aa
bb
cc
ff
The source C file is also in the ZIP.
Thx,
Christian
I'll move the PMC over to my ActivityBoard and try it again. Give me a few minutes.
Edit: I'm going out for dinner. Be back in a while.
What I found out on my side is:
When I try to write a value > 0xef the value is not written, looks like it is completely ignored. Because when I read back the values, I get the previously stored values instead the newly sent one > 0xef.
Example:
I send these byte values to the SRAM:
aa
bb
cc
dd
Then (without disconnecting the board from my laptop so that the SRAM is connected to Vdd and keeps the values), if I store the same values but the last one being ff:
dd
ab
dc
ff
and I read back the values I get back
dd,
ab
dc
dd (The value I previously stored at the same SRAM address).
Thats reproducable every time I do this.
When I store values <= 0xef it works 90% of the time.
That's really strange
Is there any board out there without any other stuff like vga, audio or other connectors? Just flash and sram and the rest of the pins routed to a header?
http://mghdesigns.com/wiki/dna:start
It has Flash and an extra 8 pin DIP - can you get an SRAM that will fit in there? (I think we tested with that)
Thanks both links, they are great. The link to http://mghdesigns.com/wiki/dna:start also includes schematic and pcb layout, thats really helpful.
I think I will use this as an idea. Thanks!
Christian
I've attached the complete SimpleIDE project with all sources. I'll also try it with different ports by myself tomorrow, now it's really late here ;-)
sqi_sram_xmem.spin
Edit: I tried this driver using P8-P15 on a QuickStart and that didn't work either. This seems very strange to me because looking at the QuickStart schematic, it looks like there is nothing connected to P8-P15. They just go to the header into which I plugged the wires that connected to the PMC on the breadboard. Something very odd happening here. I would welcome anyone looking over the code and offering advice as to how to fix this!
Edit: It works on RamPage2 as well. So, it works on DNA, RamPage2, PMC+ActivityBoard, but not PMC+QuickStart.
Because all boards use the same microcontroller, the only thing which comes to my mind which could be different is how the pins are routed from the controller
to the header. I know for high frequency applications you should not route the traces in parallel and so on. Maybe the quickstart has a different layout. But that would only
apply for higher frequencies. I attached the full SimpleIDE project of my minimal test program some messages earlier. Maybe you could enable the delay method to check, if byte output is
correct when there is a delay.
But I tried it with 100ms and above but that didn't work out, same behavior as with "full speed".
So if lowering the speed does not work, I have no other idea, what could cause the PMC + QuickStart to fail.
The quickstart works fine with shift out registers. For my pinball project I have attached a shift out register which I access via a cogc program in "full speed" and that works without any problems. The communication is also SPI like.
So I don't know, why the PMC does not like the QuickStart. Maybe some of the hardware guys from Parallax could enlighten us.
Is there an image of the QS layout available that would show which lines run adjacent to the XI trace? Maybe if these I/O pins were avoided it would resolve the problem.