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?
I guess there is something wrong with my QuadSPI code. This version just uses SPI. Got to keep looking for the bug...
I guess there is something wrong with my QuadSPI code. This version just uses SPI. Got to keep looking for the bug...
Another thing that is odd is that the SPI code doesn't seem to work on my RamPage2 board but the QuadSPI code does. So the SPI code works on the PMC and the QuadSPI code works on the RamPage2 but not the other way around. This has to be some subtle timing issue I guess. I'm going to have to break out my logic analyzer to see if I can figure out what's going wrong.
This is driving me crazy. Does anyone see anything wrong with the following SPI code? All of the masks at the bottom are setup by other code and I've verified that they are correct.
spiSendByte
shl data, #24
mov bits, #8
spiSend rol data, #1 wc
muxc outa, mosi_mask
or outa, sck_mask
andn outa, sck_mask
djnz bits, #spiSend
spiSendByte_ret
spiSend_ret
ret
spiRecvByte
mov data, #0
mov bits, #8
spiRecv or outa, sck_mask
test miso_mask, ina wc
rcl data, #1
andn outa, sck_mask
djnz bits, #spiRecv
spiRecvByte_ret
spiRecv_ret
ret
data long 0
bits long 0
mosi_mask long 0
miso_mask long 0
sck_mask long 0
Edit: I forgot to mention that this code seems to work fine on the Propeller Memory Card but not on my RamPage2 board. However, I've noticed that my RamPage2 board also doesn't match the schematic that is posted on Ray's site. I must have an earlier version that is missing the pull-up resistors on the flash and SRAM CS pins. I'm not sure if there are any other differences.
Edit2: Something else interesting is that my SQI code works fine on the RamPage2 board but not on the Propeller Memory Card. It turns out that the Propeller Memory Card has pull-up resistors on IO0-IO3. Is that normal? I thought only the CS pins were supposed to have pull-ups. Also, it looks like the pull-up on IO0 is different than the ones on IO1-3 (two resistors in series). The RamPage2 board doesn't have pull-ups on the data lines.
In my total "newbyness" of Prop assembly, I'll ask:
spiSendByte
shl data, #24
mov bits, #8
spiSend rol data, #1 wc
muxc outa, mosi_mask ' What sets the MOSI pin back to 0 when the carry is not set?
or outa, sck_mask
andn outa, sck_mask ' Does it wait to this instruction to "unset" the MOSI pin?
djnz bits, #spiSend
spiSendByte_ret
spiSend_ret
ret
In my total "newbyness" of Prop assembly, I'll ask:
spiSendByte
shl data, #24
mov bits, #8
spiSend rol data, #1 wc
muxc outa, mosi_mask ' What sets the MOSI pin back to 0 when the carry is not set?
or outa, sck_mask
andn outa, sck_mask ' Does it wait to this instruction to "unset" the MOSI pin?
djnz bits, #spiSend
spiSendByte_ret
spiSend_ret
ret
dgately
The muxc instruction just sets the MOSI pin to whatever is in the carry flag. That could be either zero or one.
@David: What's the data ready after clock high timing like (for the used h/w during read)?
From the data sheet it looks to me as though the data should be ready as soon as the clock goes high and stay ready as long as the clock remains high. The part can be clocked at up to 20mhz and I'm not clocking it anywhere near that fast.
From the data sheet it looks to me as though the data should be ready as soon as the clock goes high and stay ready as long as the clock remains high. The part can be clocked at up to 20mhz and I'm not clocking it anywhere near that fast.
Yes, that looks fine. So in other words running (for the sake of it) at 40MHz should show the same problem(s). Could there be any issues resulting from the last bit written being 0 or 1 given that that particular bit isn't cleared after the byte has been transferred? We had this problem in the past (with a counter based implementation) where outa and ctrx got in each others way.
I think you should look at table 1.2 and figures 1.2/1.3 again.
Figure 1.2 shows Serial In (from master) setup and hold timing. In this case, data must be ready (10ns) before the rising clock edge.
Figure 1.3 shows Serial Out (to master) propagation time as available (25ns) after the falling clock edge.
As I recall, your code does this, but it's hard to tell just by looking at BREAD_sram and BWRITE_sram in isolation.
I think you should look at table 1.2 and figures 1.2/1.3 again.
Figure 1.2 shows Serial In (from master) setup and hold timing. In this case, data must be ready (10ns) before the rising clock edge.
Figure 1.3 shows Serial Out (to master) propagation time as available (25ns) after the falling clock edge.
As I recall, your code does this, but it's hard to tell just by looking at BREAD_sram and BWRITE_sram in isolation.
The data is written by the muxc instruction followed immediately by setting the clock high and since each Propeller instruction takes 50nz at 80mhz the data should be available in plenty of time shouldn't it?
Yes, that looks fine. So in other words running (for the sake of it) at 40MHz should show the same problem(s). Could there be any issues resulting from the last bit written being 0 or 1 given that that particular bit isn't cleared after the byte has been transferred? We had this problem in the past (with a counter based implementation) where outa and ctrx got in each others way.
That might be a problem. I'll try setting the data line low after each transfer. Thanks.
Edit: I tried this and it didn't change the behavior.
I finally got around to hooking up a logic analyzer and immediately found a bug. Duh! Should have done that ages ago. Anyway, the RamPage2 now works in both SPI and SQI mode for the SRAM by itself and also for the combined flash/SRAM driver that I originally wrote for the Propeller Memory Card. I'm still having trouble with the SRAM on the Propeller Memory Card in SQI mode though.
While the SPI and SQI SRAM drivers work correctly on the RamPage2, I am having some trouble with the native RamPage2 driver that makes use of all four of the memory chips. The flash access seems to work fine but the SRAM test returns errors. I decided to try using my logic analyzer to diagnose this problem but found that the driver works fine with the probes connected. In fact, it works fine if I only connect a probe (along with the ground wire) to the SRAM CS pin. Any idea why the driver would only work with a probe connected to that pin?
Do you know if writing or reading fails?
I'm absolutely no electronics expert but maybe it works because the pin gets pulled to GND because of the connected probe?
Do you know if writing or reading fails?
I'm absolutely no electronics expert but maybe it works because the pin gets pulled to GND because of the connected probe?
Christian
Unfortunately, I'm not an electronics expert either. I guess that is probably obvious! :-)
Steve (jazzed) suggested that I try just touching the pins while running the test and that makes both the PMC and the RamPage2 work in all modes! He says that likely indicates some sort of timing problem so I'm reading over the SRAM data sheet to see if I can find an error in the protocol I'm using. As I said in an earlier message, I don't think it's possible to exceed the timing requirements with the Propeller as long as you don't try to change more than one pin in a single instruction which I'm not doing.
Maybe this sounds stupid but would it help if you write a small method which just waits some microseconds and call this method before setting the clock to high when sending data and before setting clock pin to low when receiving data.
If it is a timing issue then maybe this would help to test if it works at a slower speed or just setting the propeller frequency to a lower value to test if it is a timing issue...?
Maybe this sounds stupid but would it help if you write a small method which just waits some microseconds and call this method before setting the clock to high when sending data and before setting clock pin to low when receiving data.
If it is a timing issue then maybe this would help to test if it works at a slower speed or just setting the propeller frequency to a lower value to test if it is a timing issue...?
This isn't exactly what you're suggesting but I did try putting either one or two nop instructions in those places a while back with no effect.
Does anyone have any working PASM code that works with the Propeller Memory Card or any 23LC1024 board in SQI mode? I haven't been able to get either the PMC or the RamPage2 to run reliably and I don't have good enough test equipment to diagnose the failure. For the time being, neither the PMC nor the RamPage2 are usable with PropGCC. Sorry!
Yesterday night I got the flash RAM working in SPI and QPI mode. Today evening I will try to get SRAM working.
I'll post the code when everything is working but I'm not sure if this helps because it's in C, not assembler.
But maybe it's possible to get the driver as mcog into the existing framework or it is necessary to rewrite the C code in assembler.
I'll keep you posted.
Yesterday night I got the flash RAM working in SPI and QPI mode. Today evening I will try to get SRAM working.
I'll post the code when everything is working but I'm not sure if this helps because it's in C, not assembler.
But maybe it's possible to get the driver as mcog into the existing framework or it is necessary to rewrite the C code in assembler.
I'll keep you posted.
Christian
Thanks. I've never had much trouble getting the flash working on either the RamPage2 board or the PMC. It's the SRAM that is giving me trouble. I may just have some dumb error but I haven't been able to find it in spite of lots of looking. I'm interested to hear how you make out with the SRAM in SQI mode.
By the way, what did you do to get flash working? Will my driver work for accessing flash in your setup? It works okay for me.
I tried all versions of the cachetest you posted in this thread but I get lots of errors when the cache test validates the written bytes to flash.
What I mean is that flash never worked for me (only the SPI demo in spin from parallax). But you and Steve had no troubles with flash. So I thought that maybe the PMC I have has issues.
Therefore I wrote a small test C program which writes to and reads from flash and that is working. I am using QPI mode (in fact same as SQI but you can also send the command and address bytes using all four io lines) and this worked.
Today evening I will try to do the same for the sram.
I tried all versions of the cachetest you posted in this thread but I get lots of errors when the cache test validates the written bytes to flash.
What I mean is that flash never worked for me (only the SPI demo in spin from parallax). But you and Steve had no troubles with flash. So I thought that maybe the PMC I have has issues.
Therefore I wrote a small test C program which writes to and reads from flash and that is working. I am using QPI mode (in fact same as SQI but you can also send the command and address bytes using all four io lines) and this worked.
Today evening I will try to do the same for the sram.
I'll post the results today evening.
Christian
That's odd. I suppose I must have some bug that I'm not seeing myself. Any chance you'd like to take a look at the code? It's pretty simple but is unfortunately spread across a number of files. This is an attempt to factor out the common parts like cache tag handling, the mailbox loop, and SPI/SQI code so it can be used by multiple drivers. If it would help, I guess I could make a merged version that would be a single .spin file. It is all PASM code though. Are you comfortable with assembly language?
I already had a look at the code but the assembly part is really a big black box to me ;-) Maybe there is a problem with SPI/SQI interaction. As far as I understood your code, you don't use the QPI mode. So you send the command via SPI und then switch to SQI to read the data back over all 4 lines, is that correct?
I already had a look at the code but the assembly part is really a big black box to me ;-) Maybe there is a problem with SPI/SQI interaction. As far as I understood your code, you don't use the QPI mode. So you send the command via SPI und then switch to SQI to read the data back over all 4 lines, is that correct?
The SRAM code sends commands in quad mode. The Winbond flash code doesn't because I think the chips I originally wrote it for don't allow that. In any case, the my driver that only handles SRAM and doesn't even touch the flash still doesn't work correctly. Anyway, I'm glad to hear you got your flash code working.
I just looked at Winbond QPI mode and it looks like they just copied the way the SST chips work. Except for needing to set the QE bit in status register 2 to allow QPI mode, it looks like the rest of my SST code will work for the Winbond QPI-capable chips.
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.
Comments
spiSendByte shl data, #24 mov bits, #8 spiSend rol data, #1 wc muxc outa, mosi_mask or outa, sck_mask andn outa, sck_mask djnz bits, #spiSend spiSendByte_ret spiSend_ret ret spiRecvByte mov data, #0 mov bits, #8 spiRecv or outa, sck_mask test miso_mask, ina wc rcl data, #1 andn outa, sck_mask djnz bits, #spiRecv spiRecvByte_ret spiRecv_ret ret data long 0 bits long 0 mosi_mask long 0 miso_mask long 0 sck_mask long 0Edit: I forgot to mention that this code seems to work fine on the Propeller Memory Card but not on my RamPage2 board. However, I've noticed that my RamPage2 board also doesn't match the schematic that is posted on Ray's site. I must have an earlier version that is missing the pull-up resistors on the flash and SRAM CS pins. I'm not sure if there are any other differences.
Edit2: Something else interesting is that my SQI code works fine on the RamPage2 board but not on the Propeller Memory Card. It turns out that the Propeller Memory Card has pull-up resistors on IO0-IO3. Is that normal? I thought only the CS pins were supposed to have pull-ups. Also, it looks like the pull-up on IO0 is different than the ones on IO1-3 (two resistors in series). The RamPage2 board doesn't have pull-ups on the data lines.
In my total "newbyness" of Prop assembly, I'll ask:
spiSendByte shl data, #24 mov bits, #8 spiSend rol data, #1 wc muxc outa, mosi_mask ' What sets the MOSI pin back to 0 when the carry is not set? or outa, sck_mask andn outa, sck_mask ' Does it wait to this instruction to "unset" the MOSI pin? djnz bits, #spiSend spiSendByte_ret spiSend_ret retdgately
I get it now!
Thanks,
dgately
http://ww1.microchip.com/downloads/en/DeviceDoc/25142A.pdf
I think you should look at table 1.2 and figures 1.2/1.3 again.
Figure 1.2 shows Serial In (from master) setup and hold timing. In this case, data must be ready (10ns) before the rising clock edge.
Figure 1.3 shows Serial Out (to master) propagation time as available (25ns) after the falling clock edge.
As I recall, your code does this, but it's hard to tell just by looking at BREAD_sram and BWRITE_sram in isolation.
Edit: I tried this and it didn't change the behavior.
Thanks!
David
cachetest.zip
Do you know if writing or reading fails?
I'm absolutely no electronics expert but maybe it works because the pin gets pulled to GND because of the connected probe?
Christian
Steve (jazzed) suggested that I try just touching the pins while running the test and that makes both the PMC and the RamPage2 work in all modes! He says that likely indicates some sort of timing problem so I'm reading over the SRAM data sheet to see if I can find an error in the protocol I'm using. As I said in an earlier message, I don't think it's possible to exceed the timing requirements with the Propeller as long as you don't try to change more than one pin in a single instruction which I'm not doing.
If it is a timing issue then maybe this would help to test if it works at a slower speed or just setting the propeller frequency to a lower value to test if it is a timing issue...?
Yesterday night I got the flash RAM working in SPI and QPI mode. Today evening I will try to get SRAM working.
I'll post the code when everything is working but I'm not sure if this helps because it's in C, not assembler.
But maybe it's possible to get the driver as mcog into the existing framework or it is necessary to rewrite the C code in assembler.
I'll keep you posted.
Christian
By the way, what did you do to get flash working? Will my driver work for accessing flash in your setup? It works okay for me.
What I mean is that flash never worked for me (only the SPI demo in spin from parallax). But you and Steve had no troubles with flash. So I thought that maybe the PMC I have has issues.
Therefore I wrote a small test C program which writes to and reads from flash and that is working. I am using QPI mode (in fact same as SQI but you can also send the command and address bytes using all four io lines) and this worked.
Today evening I will try to do the same for the sram.
I'll post the results today evening.
Christian
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 ;-)