23LC1024 SPI RAM driver insanity
Wuerfel_21
Posts: 5,053
in Propeller 1
I am literally descending into insanity right now and all I've got to blame is a little eight-leggy boi.
Since I couldn't find any Spin/PASM drivers for it, I tried writing my own. Oddly, the RAM seems to be really picky with the drivers:
naiveram.spin - seems to work, but super slow
sdiram.spin - uses SDI mode, slightly less slow, but reliable (and can be used together with an SD driver)
sdiram_seq.spin - like sdiram, except it tries to reduce the amount of commands sent by keeping the session going between calls. Works only with some access patterns? Puzzled.
23lc1024.spin - attempt to write a PASM driver. (in8 and out8 are confirmed to work with the RAM) Seems to stop working after sdiram ACCESSES the RAM (initializing it to SDI mode is fine?) until it is powercycled. Also potentially depends on the phase of the moon and the weather.
Can someone please tell me what I'm missing? (Or point me to a PASM driver that works?)
Since I couldn't find any Spin/PASM drivers for it, I tried writing my own. Oddly, the RAM seems to be really picky with the drivers:
naiveram.spin - seems to work, but super slow
sdiram.spin - uses SDI mode, slightly less slow, but reliable (and can be used together with an SD driver)
sdiram_seq.spin - like sdiram, except it tries to reduce the amount of commands sent by keeping the session going between calls. Works only with some access patterns? Puzzled.
23lc1024.spin - attempt to write a PASM driver. (in8 and out8 are confirmed to work with the RAM) Seems to stop working after sdiram ACCESSES the RAM (initializing it to SDI mode is fine?) until it is powercycled. Also potentially depends on the phase of the moon and the weather.
Can someone please tell me what I'm missing? (Or point me to a PASM driver that works?)
Comments
To ensure SPI mode is ever accessible, after using any of SDI or SQI modes you'll need to ensure a RSTIO CMD would be issued (e.g., writeval($ffff,16) 'reset to SPI mode; presently at sdiram.spin), at the very end of any routines that could eventually have made use of any of the other two modes, to force the SRAM to return to SPI mode, before attempting to use it within your in8 and out8 routines.
If you are transitioning modes on the wild, perhaps it's a good idea to have a commonly available variable (global??), where the current mode is saved, so as to give each driver a chance to set its preferred mode, and be able to return to a commom standard when it gives-up its command sequences.
Hope it helps a bit
Henrique
Also notable: the resting state of the clock is LOW and the RAM latches the bits on RISING edges.
You might want to check into Rayman's page including his drivers:
http://www.rayslogic.com/Propeller/Products/FlashPoint/FlashPoint.htm
Yes, ISSI have parts up to 45MHz and up to 4Mb in SO8 packages.
http://www.issi.com/US/product-asynchronous-sram.shtml#jump5
A working driver is attached.
Bugs are bugs, either being additive or subtractive ones.
But one of the phrases you've used at the first post "Also potentially depends on the phase of the moon and the weather." did made me wonder if that was not one of the kind of "ghost-active" bugs, the worse of all, in fact.
Ghosts aparted, problem solved. Good to know you've nailed it down!
Henrique
Better staying with the good-old-days test/sniffing procedures. Dealing with fuming remains of FR-4 and epoxy-packaged components could endanger your eyes and nose, as a minimum.