Shop OBEX P1 Docs P2 Docs Learn Events
Operation of 23K256 or 23K640 Microchip Serial SRAM on BS2p (or BS2) — Parallax Forums

Operation of 23K256 or 23K640 Microchip Serial SRAM on BS2p (or BS2)

gschreibgschreib Posts: 16
edited 2011-07-29 22:18 in BASIC Stamp
Hello,
I'd like to know if anyone has actually been able to download bytes into either one of these IC's and retrieve those bytes back again using the BS2p or BS2. I've been working on this problem for over two weeks, using both the 23K256 and the 23K640 SSRAM. I have read and understood both the datasheets and the pertinent Application Notes that show, and explain, the explicit timing diagrams for the Status Register and data Write/Reads.
Using a Tek TDS210 digital 'scope to look at SO with respect to the SCK. I have level shifted into the SSRAM's, and have put in the proper Status Register instruction(s) and data byte(s). I can see the instructions, addresses and data going into SI pin with the proper relationship to the SCK (the clock).
What I get out bears little relation to what I've put in, and even those erroneous "reads" are not
consistent. They are not faulty chips (I have bought three separate batches). Leads going in and out
are short and coaxed to avoid capacitive coupling, and the HOLD_ is tied to Vdd and the supplies are properly bypassed. CS_ is resistively pulled up and operated according to the datasheets and App Notes, etc. I have even bit banged SCK to adjust the READ timing. Nada. I feel that there is something simple that I'm not catching here, but I'm actually wondering if anyone has actually got these to work in a real Basic Stamp circuit.
Can anyone shed any light on this problem. It's like the Roach Motel. The Bytes go in but they
don't come out (right). Thanks...

Comments

  • RickBRickB Posts: 395
    edited 2011-07-24 13:59
    A labeled schematic of your actual circuit and the minimum code necessary to reproduce the problem would help immensely.
  • gschreibgschreib Posts: 16
    edited 2011-07-24 17:44
    Hi RickB,
    Sorry, I'm new and this is the third time I'm trying to construct this letter. I've lost the last two to the ether, or something. My letters are getting shorter as I'm wearing out. I have a .bs2 file of the most recent try at the code. The last time I moved the file icon to the vicinity of my writing I lost the whole thing again. I beg your pardon, but how do I attach this code file to this letter? If I can get the code over to you I'd like to make the schematic up. Then we could talk about how I'd get that over to you. Sometimes I miss the plastic slide-rule, clipboard and pencil. I know that I couldn't do as much, but at least I could do it. Thank you for your time.
    gschreib
  • Mike GreenMike Green Posts: 23,101
    edited 2011-07-24 20:34
    When you click on "Reply to Thread", under the reply window is a button "Go Advanced". If you click on that, you'll get a more complex reply window that includes an attachment manager that allows you to attach various files to your message.
  • gschreibgschreib Posts: 16
    edited 2011-07-25 01:56
    Thank you for your reply. Attached (I hope), is one of the .bs2 code attempts I made to interface the 23K256 and 23K640 Serial SRAM's to the BS2p (or it's slower cousin BS2). The goal is a 102 byte
    (or multiples thereof) line buffer for the TLS3301 linear optical array, the code of which was successfully written a few weeks ago. Byte data will be processed by the umFPU-V3.1 with which I have become somewhat vaguely semi-competent. In any case, if this attachment is visible, you can infer at least one of the many unsuccessful routes I have tried to get these SSRAM's safely tucked in my "Codelet Drivers" files. However, I'll need to work up a schematic, and the only tool available to me at the moment is the newly purchased DipTrace package (with schematic capture), with which I am barely familiar. If there
    are any ideas on what other app. would be acceptable and obtainable for doing up the circuit I would be appreciative. I guess that the file extension would have to be one of those delineated in the "list". This is my first forum attempt, and I just don't have any experience about what is generally done about the schematic problem. Please let me know if the "attachment" is attached. Thanks for the help.
  • gschreibgschreib Posts: 16
    edited 2011-07-25 05:58
    23K256-worksheet-8.bspLet me try to attach the code file again.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-07-25 21:54
    I think you're running into problems with an undefined clock pin state. I would put a "LOW sck" statement before each "LOW cs" so the state of the clock pin is defined before the first SHIFTOUT statement of each group. It's probably not necessary, but I would combine the SHIFTOUT statements for each transaction like:

    SHIFTOUT si, sck, MSBFIRST, [%00000001, %00000001] ' write to status register to disable HOLD
  • gschreibgschreib Posts: 16
    edited 2011-07-26 11:02
    Hi Mike,
    Thanks for the information on the undefined clock state pin. I put the "LOW sck" statements in and it did clear up some of the random output data. That means it was part of a larger problem. I also suspect
    that my simple resistance dividers from the BS2p to the 3.3v SSRAM may be the bulk, if not all, of the rest of the problem. I should have known better than to fall into that kind of lazy solution. Just ordered some of those 74LCX126M quad "5 volt tolerant" buffer/drivers to do the level shifting the proper way. And since they're SOIC, I had to buy those SMD to DIP adapters too. After I put in those sck statements I found that putting in $FF resulted in $FF it the data output. And putting in $00 results in $00 out. I didn't have them both working consistently before. Good suggestion. The numbers in-between 1 and 254 aren't consistent. I'm hoping that the buffers will clear that up. By the way, you saved me double-time on consolidating those SHIFTOUT statements. They're shorter and faster to type and save page real estate. But just as important is the fact that when I glue two of those SHIFTOUT statements together, it saves 80us in execution time. And the more I can "bracket-in", the more time I save. Doesn't sound like much, but I've got 102 bytes per line on the TSL3301 and I want to acquire 100 lines in real time before I start the math processing. The acquisition time counts. The post-processing doesn't. So thanks for the help. I'll let you know if those buffers clean it up... gschreib
  • Mike GreenMike Green Posts: 23,101
    edited 2011-07-26 12:11
    I know it's kind of late in the game, but I'd put in a plug for the Propeller. Any time you've got a time-dependent situation, the extra speed of the Propeller is a real boon not to mention that you have essentially 8 identical microprocessors rather than just one. I haven't looked to see whether there's a driver already written for the TSL3301 in the Object Exchange, but there may be. There's already a driver for the 32K256 that handles one or two of them. Since the Propeller is a 3.3V device, you wouldn't need the buffers and the TSL3301 can run off 3.3V as well.

    With the Prop's 32K of hub RAM, you might even do away with the 23K256 since you only need a 10K byte buffer for a 100 x 100 pixel image. The SpinStamp might be able to plug into your setup with some minor changes (like series 2.2K resistors in the I/O leads).
  • gschreibgschreib Posts: 16
    edited 2011-07-26 15:26
    Hi Mike,
    Yes, there's no question that I'm using the wrong hardware for this application. And I'll have to change over to the Propeller if I get to the LCD graphic readout part of this project. But for now, I just want to bask in the programming simplicity of the BS2. There are pieces of this project that can be done as a "proof of concept" on the Basic Stamp. And it's easy to program without all the attendant problems associated with the more sophisticated languages. For now, I'm just having fun. But I'm willing to change up when the time comes. I'll let you know. Thanks for the tip and all the help.- gschreib
  • gschreibgschreib Posts: 16
    edited 2011-07-29 22:18
    Hi Mike,
    Thanks for your forum and support. This SSRAM problem is now solved for the 23K256 and 23K640 interfaced to BS2p. Used 74LCX126 as a level-shifter/buffer into the SSRAM's to accommodate the differences required between the two separate Vdd's. The passive interface (resistor dividers or series resistors with zeners ) simply didn't work. Or I should say that I couldn't get the passive interface to work, although the voltage levels looked fine on the 'scope. The level-shifter chip idea came from your (Propeller?) forum on the same subject. That cinched it. For anyone wishing to use these SSRAM's, I suggest Microchip's Application Note AN1287. The timing diagrams and chip connections can be clearly and easily understood. Thanks again! - gschreib
Sign In or Register to comment.