Hmmm... I guess I'd better check my SRAM code although trancefreak had trouble with flash as well. Maybe there is a timing issue in the SPI code. I wish I had a board that failed. The two I have (one old prototype and one production board) have both worked for me.
I don't know if this means anything but I notice that your resistor packs are backwards compared with mine. In other words, the "104" lettering is inverted from what is on my board. Does the lettering indicate the correct orientation or is it just random? Actually, I suppose it doesn't matter since they're resistors but that's the only difference I can see between my board and yours.
Though, re-running your latest cachetest a few more times gives "good" results now (weird). But, there's a chance that my initial run was with your previous cachetest (from earlier in the thread).
propeller-load -b activityboard -p /dev/cu.usbserial-A1013PDN cachetest.elf r -t -S
Propeller Version 1 on /dev/cu.usbserial-A1013PDN
Loading cachetest.elf to hub memory
13704 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
mbox 00003588
cache 00003594
buf 00005794
Big flash test
Start value 30007a31
Filling flash
Checking flash
Filling flash inverted
Checking flash inverted
done
Big RAM test
Filling RAM
Start value 200046a4
Checking RAM
Filling RAM inverted
Checking RAM inverted
done
cache test
done
Either way, it's strange, since one test succeeds and the other does not.
EDIT: Arg! After unplugging my QuickStart and retrying the Demo, it's now succeeding. I'm not sure what gives here, but there seems to be intermittent problems. I'll re-run a number of tests again and see if there's any pattern.
Either way, it's strange, since one test succeeds and the other does not.
dgately
I suppose there could be marginal timing in my SPI/SQI code such that it works differently depending on how long the board has been powered on or something like that. That doesn't explain why the Spin test fails though.
That doesn't explain why the Spin test fails though.
Well, It's not failing right now. I've re-run the Demo and it succeeds. I updated the Demo code to dump the first 64 bytes of SRAM after it "randomizes" them and it does have random data written to it. That data then gets trumped when it writes the "Hello World" text. So, the demo is successful. BTW: I'm using the openspin compiler within SimpleIDE, cause "that's how I roll!" :cool:
To note: make sure not to just reset between tests as SRAM looks to survive the reset process and at least the first 64 bytes stay alive, sometimes...
Also, my QuickStart became unreachable from SimpleIDE several times between my initial tests (not happening now). I had to reset it just to be able to get SimpleIDE to reach the QS. It's possible that there was a configuration issue at the time (possible the SD card had left-over xmmc-sd bits?). Could that have caused my initial failures?
Anyway, the tests and demos seem to be working on my QuickStart now.
Well, It's not failing right now. I've re-run the Demo and it succeeds. I updated the Demo code to dump the first 64 bytes of SRAM after it "randomizes" them and it does have random data written to it. That data then gets trumped when it writes the "Hello World" text. So, the demo is successful. BTW: I'm using the openspin compiler within SimpleIDE, cause "that's how I roll!" :cool:
To note: make sure not to just reset between tests as SRAM looks to survive the reset process and at least the first 64 bytes stay alive, sometimes...
Also, my QuickStart became unreachable from SimpleIDE several times between my initial tests (not happening now). I had to reset it just to be able to get SimpleIDE to reach the QS. It's possible that there was a configuration issue at the time (possible the SD card had left-over xmmc-sd bits?). Could that have caused my initial failures?
Anyway, the tests and demos seem to be working on my QuickStart now.
dgately
Ugh. Working sometimes but not always is not a happy state. Thanks for testing though!
Files on the SD card should have no effect unless you also used -e to write a boot program to your EEPROM to boot the SD program. Of course, having the SD card inserted could cause my cachetest program to fail until I add the code to force the SD card into SPI mode at cache driver initialization.
It certainly doesn't look good. I suppose it could be some timing problem in my driver that causes problems for some PMC boards but not others. How do you have your board wired up? Maybe I can try to duplicate your exact setup. In other words, what board are you using and how do you have the PMC connected? Wire length, etc?
I have attached images of the wire length and my setup I'm using. It's a standard breadboard with the wires I got with it. On the first image (if you enlarge it) the chip numbers are readable. If you have a breadboard maybe you can test if it works with your setup or if you get the same results as myself.
@David Carrier:
I just checked the resistance of all the pins:
All CS pins have about 100K, but the others also (data lines) except IO0/DI which has 200k. CLK has no connection to Vdd.
In my absence I saw that dgately also hat a problem with the test the first time he tried but then was successfull the other tests. But the spin SRAM is also failing for him.
Does that indicate that there might be no problem with the board but with the spin test?
@DavidBetz: I can't recompile the test c program you posted because I don't have all the drivers/sources needed. Please could you compile a version with the CS pins not being 5 & 6 (e.g. 8,9 as David C suggested), if you have time of course. I'll do a new test then.
Ok, my daughter is in bed now and is sleeping She is really miffed the last days
I have attached images of the wire length and my setup I'm using. It's a standard breadboard with the wires I got with it. On the first image (if you enlarge it) the chip numbers are readable. If you have a breadboard maybe you can test if it works with your setup or if you get the same results as myself.
@David Carrier:
I just checked the resistance of all the pins:
All CS pins have about 100K, but the others also (data lines) except IO0/DI which has 200k. CLK has no connection to Vdd.
In my absence I saw that dgately also hat a problem with the test the first time he tried but then was successfull the other tests. But the spin SRAM is also failing for him.
Does that indicate that there might be no problem with the board but with the spin test?
@DavidBetz: I can't recompile the test c program you posted because I don't have all the drivers/sources needed. Please could you compile a version with the CS pins not being 5 & 6 (e.g. 8,9 as David C suggested), if you have time of course. I'll do a new test then.
Regards,
Christian
Are you comfortable with the command line and makefiles? I can send you buildable sources. You'll need spin2cpp though since that is what is used to build the driver. I think that comes with SimpleIDE so it may not be a problem. In any case, I can rebuild it for you and send you one that uses P8 and P9.
Thanks very much for the rebuilt version. I'm not that familiar with makefiles and C itself. I'm just learning C because it's the first time I get in touch with microcontrollers. I'm only used to perl, Java and .NET.
I executed the modified test program, but that didn't solve my issues.
Here is the beginning of the output:
C:\Users\Christian\Documents\SimpleIDE\MemoryCardTest\CacheTest_Pins8_9>propelle
r-load cachetest.elf -r -t
Propeller Version 1 on COM3
Loading cachetest.elf to hub memory
13704 bytes sent
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
mbox 00003588
cache 00003594
buf 00005794
Big flash test
Start value 30007351
Filling flash
Checking flash
30000280: expected 300073f1, found 0f033017
30000284: expected 300073f2, found 0f033027
30000288: expected 300073f3, found 0f033037
3000028c: expected 300073f4, found 0f033047
30000290: expected 300073f5, found 0f033057
30000294: expected 300073f6, found 0f033067
30000298: expected 300073f7, found 0f033077
3000029c: expected 300073f8, found 0f033087
300002a0: expected 300073f9, found 0f033097
300002a4: expected 300073fa, found 0f0330a7
300002a8: expected 300073fb, found 0f0330b7
300002ac: expected 300073fc, found 0f0330c7
300002b0: expected 300073fd, found 0f0330d7
300002b4: expected 300073fe, found 0f0330e7
300002b8: expected 300073ff, found 000330f7
300002bc: expected 30007400, found 00034007
300002c0: expected 30007401, found 00034017
300002c4: expected 30007402, found 00034027
300002c8: expected 30007403, found 00034037
300002cc: expected 30007404, found 00034047
300002d0: expected 30007405, found 00034057
300002d4: expected 30007406, found 00034067
300002d8: expected 30007407, found 00034077
300002dc: expected 30007408, found 00034087
300002e0: expected 30007409, found 00034097
300002e4: expected 3000740a, found 000340a7
300002e8: expected 3000740b, found 000340b7
300002ec: expected 3000740c, found 000340c7
300002f0: expected 3000740d, found 000340d7
300002f4: expected 3000740e, found 000340e7
300002f8: expected 3000740f, found 010340f7
300002fc: expected 30007410, found 01034007
30000680: expected 300074f1, found 0f034017
30000684: expected 300074f2, found 0f034027
30000688: expected 300074f3, found 0f034037
3000068c: expected 300074f4, found 0f034047
30000690: expected 300074f5, found 0f034057
30000694: expected 300074f6, found 0f034067
30000698: expected 300074f7, found 0f034077
3000069c: expected 300074f8, found 0f034087
300006a0: expected 300074f9, found 0f034097
300006a4: expected 300074fa, found 0f0340a7
300006a8: expected 300074fb, found 0f0340b7
300006ac: expected 300074fc, found 0f0340c7
300006b0: expected 300074fd, found 0f0340d7
300006b4: expected 300074fe, found 0f0340e7
300006b8: expected 300074ff, found 000340f7
300006bc: expected 30007500, found 00035007
300006c0: expected 30007501, found 00035017
300006c4: expected 30007502, found 00035027
300006c8: expected 30007503, found 00035037
300006cc: expected 30007504, found 00035047
300006d0: expected 30007505, found 00035057
300006d4: expected 30007506, found 00035067
300006d8: expected 30007507, found 00035077
300006dc: expected 30007508, found 00035087
300006e0: expected 30007509, found 00035097
300006e4: expected 3000750a, found 000350a7
300006e8: expected 3000750b, found 000350b7
300006ec: expected 3000750c, found 000350c7
300006f0: expected 3000750d, found 000350d7
300006f4: expected 3000750e, found 000350e7
300006f8: expected 3000750f, found 010350f7
300006fc: expected 30007510, found 01035007
30000a80: expected 300075f1, found 0f035017
30000a84: expected 300075f2, found 0f035027
30000a88: expected 300075f3, found 0f035037
30000a8c: expected 300075f4, found 0f035047
30000a90: expected 300075f5, found 0f035057
30000a94: expected 300075f6, found 0f035067
30000a98: expected 300075f7, found 0f035077
30000a9c: expected 300075f8, found 0f035087
30000aa0: expected 300075f9, found 0f035097
30000aa4: expected 300075fa, found 0f0350a7
30000aa8: expected 300075fb, found 0f0350b7
30000aac: expected 300075fc, found 0f0350c7
30000ab0: expected 300075fd, found 0f0350d7
30000ab4: expected 300075fe, found 0f0350e7
30000ab8: expected 300075ff, found 000350f7
30000abc: expected 30007600, found 00036007
30000ac0: expected 30007601, found 00036017
30000ac4: expected 30007602, found 00036027
30000ac8: expected 30007603, found 00036037
30000acc: expected 30007604, found 00036047
30000ad0: expected 30007605, found 00036057
30000ad4: expected 30007606, found 00036067
30000ad8: expected 30007607, found 00036077
30000adc: expected 30007608, found 00036087
30000ae0: expected 30007609, found 00036097
30000ae4: expected 3000760a, found 000360a7
30000ae8: expected 3000760b, found 000360b7
30000aec: expected 3000760c, found 000360c7
30000af0: expected 3000760d, found 000360d7
30000af4: expected 3000760e, found 000360e7
30000af8: expected 3000760f, found 010360f7
30000afc: expected 30007610, found 01036007
30000e80: expected 300076f1, found 0f036017
30000e84: expected 300076f2, found 0f036027
30000e88: expected 300076f3, found 0f036037
30000e8c: expected 300076f4, found 0f036047
30000e90: expected 300076f5, found 0f036057
30000e94: expected 300076f6, found 0f036067
30000e98: expected 300076f7, found 0f036077
30000e9c: expected 300076f8, found 0f036087
30000ea0: expected 300076f9, found 0f036097
30000ea4: expected 300076fa, found 0f0360a7
30000ea8: expected 300076fb, found 0f0360b7
30000eac: expected 300076fc, found 0f0360c7
30000eb0: expected 300076fd, found 0f0360d7
30000eb4: expected 300076fe, found 0f0360e7
30000eb8: expected 300076ff, found 000360f7
30000ebc: expected 30007700, found 00037007
30000ec0: expected 30007701, found 00037017
30000ec4: expected 30007702, found 00037027
30000ec8: expected 30007703, found 00037037
30000ecc: expected 30007704, found 00037047
30000ed0: expected 30007705, found 00037057
30000ed4: expected 30007706, found 00037067
30000ed8: expected 30007707, found 00037077
30000edc: expected 30007708, found 00037087
30000ee0: expected 30007709, found 00037097
30000ee4: expected 3000770a, found 000370a7
30000ee8: expected 3000770b, found 000370b7
30000eec: expected 3000770c, fou^C
C:\Users\Christian\Documents\SimpleIDE\MemoryCardTest\CacheTest_Pins8_9>
It looks like writing / reading from flash works in the beginning because the first wrong readback value happens at address:
30000280: expected 300073f1, found 0f033017
From that point each long is wrong.
I'll execute the spin test program with the changed cs pins and post the result also.
Maybe it's really just a simple SPI timing issue?
It's the same result as in my previous test. Flash works but SRAM not but maybe theres also a problem with the spin code.
Would be great if you could find out what's causing the issues
Do you think it is easily possible to lower the SPI clock speed of the cache to check if that makes things better?
from your post:
30000280: expected 300073f1, found 0f033017 <== Notice how the data "is" being incremented!
30000284: expected 300073f2, found 0f033027 <== Something is definitely being written in a pattern to the SRAM,
30000288: expected 300073f3, found 0f033037 <== It's almost as if there is a problem on the data bus (note the endianness difference of the low bytes. They're swapped)...
3000028c: expected 300073f4, found 0f033047
30000290: expected 300073f5, found 0f033057
30000294: expected 300073f6, found 0f033067
30000298: expected 300073f7, found 0f033077
3000029c: expected 300073f8, found 0f033087
300002a0: expected 300073f9, found 0f033097
[/QUOTE]
I always look for patterns when debugging. Looks like there's something going on here (not what was expected, but "something" is getting written, incrementally into the SRAM).
I always look for patterns when debugging. Looks like there's something going on here (not what was expected, but "something" is getting written, incrementally into the SRAM).
Hmmm... must be some timing problem with my SPI or SQI code I guess. It works on the two boards I have so I'm not sure how to diagnose the problem. Are you using QS+HIB+PMC?
Hmmm... must be some timing problem with my SPI or SQI code I guess. It works on the two boards I have so I'm not sure how to diagnose the problem. Are you using QS+HIB+PMC?
But it's interesting why dgately experienced the same result with the spin demo and SRAM test as I did. After writing "Hello world!" the SRAM was still completely blank.
I hope we can find out the reason why the memory card isn't reliably working.
Please let me know if you need me to do some tests on my board or anything else.
I'm looking at this again but this time I'm trying to add SD initialization so that you don't have to remove the SD card to run the test and I'm running into some strange problems. There must be some bug lurking in my code that I haven't found yet. :-(
I'm afraid I can't figure out what's wrong with this driver. Here is my latest source including code to initialize the SD card. It seems to work for me if an SD card is inserted but not if there is no SD card. Also, the SRAM test isn't even reliable on my board anymore. All of the files needed to build the test program are in this zip file along aith a Makefile in case anyone would like to help figure out why this isn't working. I'll get back to it later tonight.
David, thanks for the really hard work you put into finding the issue. I'll have a look at the sources today evening when I'm at home. I'm in the office right now so I can't do any tests.
I just tried this same cache driver with the RamPage2 memory board and it seems to run fine there. However, the RamPage2 does not share pins between the SD card and the flash and SRAM so there was no need to initialize the SD card. Also, this driver only uses half of the memory chips on the RamPage2 since it has two flash chips and two SRAM chips. However, the basic flash and SRAM tests work fine.
Edit: Also, the RamPage2 board uses SST flash chips instead of Winbond chips so it uses slightly different code in the sqi_flash_sram_xcache driver.
I'm afraid I can't figure out what's wrong with this driver. Here is my latest source including code to initialize the SD card. It seems to work for me if an SD card is inserted but not if there is no SD card.
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.
Comments
That's failing as well for the SRAM:
Though, re-running your latest cachetest a few more times gives "good" results now (weird). But, there's a chance that my initial run was with your previous cachetest (from earlier in the thread).
Either way, it's strange, since one test succeeds and the other does not.
EDIT: Arg! After unplugging my QuickStart and retrying the Demo, it's now succeeding. I'm not sure what gives here, but there seems to be intermittent problems. I'll re-run a number of tests again and see if there's any pattern.
dgately
Well, It's not failing right now. I've re-run the Demo and it succeeds. I updated the Demo code to dump the first 64 bytes of SRAM after it "randomizes" them and it does have random data written to it. That data then gets trumped when it writes the "Hello World" text. So, the demo is successful. BTW: I'm using the openspin compiler within SimpleIDE, cause "that's how I roll!" :cool:
To note: make sure not to just reset between tests as SRAM looks to survive the reset process and at least the first 64 bytes stay alive, sometimes...
Also, my QuickStart became unreachable from SimpleIDE several times between my initial tests (not happening now). I had to reset it just to be able to get SimpleIDE to reach the QS. It's possible that there was a configuration issue at the time (possible the SD card had left-over xmmc-sd bits?). Could that have caused my initial failures?
Anyway, the tests and demos seem to be working on my QuickStart now.
dgately
Files on the SD card should have no effect unless you also used -e to write a boot program to your EEPROM to boot the SD program. Of course, having the SD card inserted could cause my cachetest program to fail until I add the code to force the SD card into SPI mode at cache driver initialization.
I have attached images of the wire length and my setup I'm using. It's a standard breadboard with the wires I got with it. On the first image (if you enlarge it) the chip numbers are readable. If you have a breadboard maybe you can test if it works with your setup or if you get the same results as myself.
@David Carrier:
I just checked the resistance of all the pins:
All CS pins have about 100K, but the others also (data lines) except IO0/DI which has 200k. CLK has no connection to Vdd.
In my absence I saw that dgately also hat a problem with the test the first time he tried but then was successfull the other tests. But the spin SRAM is also failing for him.
Does that indicate that there might be no problem with the board but with the spin test?
@DavidBetz: I can't recompile the test c program you posted because I don't have all the drivers/sources needed. Please could you compile a version with the CS pins not being 5 & 6 (e.g. 8,9 as David C suggested), if you have time of course. I'll do a new test then.
Regards,
Christian
cachetest.zip
Warning: This will not work on anything other than trancefreak's modified setup.
Thanks very much for the rebuilt version. I'm not that familiar with makefiles and C itself. I'm just learning C because it's the first time I get in touch with microcontrollers. I'm only used to perl, Java and .NET.
I executed the modified test program, but that didn't solve my issues.
Here is the beginning of the output:
It looks like writing / reading from flash works in the beginning because the first wrong readback value happens at address:
30000280: expected 300073f1, found 0f033017
From that point each long is wrong.
I'll execute the spin test program with the changed cs pins and post the result also.
Maybe it's really just a simple SPI timing issue?
It's the same result as in my previous test. Flash works but SRAM not but maybe theres also a problem with the spin code.
Would be great if you could find out what's causing the issues
Do you think it is easily possible to lower the SPI clock speed of the cache to check if that makes things better?
Regards,
Christian
[/QUOTE]
I always look for patterns when debugging. Looks like there's something going on here (not what was expected, but "something" is getting written, incrementally into the SRAM).
dgately
I've never run your test program before today. Other programs worked fine without the SD Card.
Just with SRAM. I couldn't build with the .C file, so I used the TK Loader.
Yes,
I'm not in much of a debugging position tonight.
I hope we can find out the reason why the memory card isn't reliably working.
Please let me know if you need me to do some tests on my board or anything else.
Regards,
Christian
cachetest.zip
Christian
Edit: Also, the RamPage2 board uses SST flash chips instead of Winbond chips so it uses slightly different code in the sqi_flash_sram_xcache driver.
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