I haven't dug too deep into your code, mainly because it worked with the '256 and you made adjustments to the adr length. So I'm thinking you could have s slight difference between the two chips. I found a note in the 23xx1024 DS in Fig 3.8 that notes 3 Pin should not be left floating with Non-SQI operations.The text doesn't say a word about that and the pin diag shows it as NC. This is different then on the '256 where Pin 3 is a NC. Don't know if you made this change to you layout and don't know what happens if it IS floating but that's the only diff I can see so far.

Yeah, saw that. I bring pin 3 to Vdd. I read the same "is it is it or is in not is it...". I haven't tried grounding pin 3 yet...

When I did the piggy back, I left the 23K256 pin 3 float. It worked, the 23LC1024 did not. The only thing that was going on was a write to the mode register and a read from the mode register that went "forever". This produces an obvious toggling signal on the 23K256, but not on the 23LC1024. The program sends an 8 bit command (write or read mode register) and 8 bits of data then sends an mode register read command and gets an 8 bit response. The command data is the same for both ICs, so this program should work with both. Having now tried two 23LC1024 ICs, I'm leaning toward "I got bad ICs"... I know how improbable that is..._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

Just went through the 'loop' routine, seems simple enough. During the WRMR sequence, MISO stays HiZ. During the RDMR sequence, MISO should be HiZ for the first 8 clocks, then Hi/Lows for the last 8 clocks. If it works with a '256 then should work with '1024, same instructions/sequences .
As far as Pin3 the DS doesn't say what level to tie it to, so either that means either state (but Vdd didn't work), or we just got'a guess. Don't think it matters on the '256, but the '1024 has the SDI/SQI mode (don't know about these modes, more research to do). If Vss on P.3 doesn't help then it may be a dead bug ?!?!
I've got 3 samples coming, you'r welcome to a couple. I don't know when they will be here, ordered them 2 or 3 days ago( MC is pretty fast most times) PM me if you want them.
EDIT-Just went through AN 1484 It recommends that 10K pull ups on /CS, /HOLD and Pin 3. It notes that Pin 3 can be pulled low, but on exit from SQI mode it needs to go high, so that is the preferred idle state. Also mentioned that if Vcc sags below Op levels, should do a full pwr cycle reset.

I have AN1484 here (01484A.pdf), did the pullups and pin 3 is pulled high. I have a thread open on the Microchip forum about this. I'll wait and see what they say there before I do anything else. It really looks like a bad IC or a mismarked IC. (well, 2 bad or mismarked ones). Definately works with 23K256 and fails with 23LC1024.

Well the board's mostly done but waiting for the '1024s to show up. In the interim, I'll be adding some ifdefs for the PLL setup and remapping the SPI pins; I've built it based on the RoninSynth setup. So I'll let you know in the next few days, once I blinken de LEDs

I got this from a Microchip forum member. I looked at that bit and thought "well, the worst that can happen is bad data". Not so. When I CLEAR that bit, toggle of the SRAM chip stops and the SO line (pin2) remains at Vss (zero volts).

After setting the bit and retesting, I see toggling on pin 2. Then I ran the full data reliability test and it started to pass immediately. Just to make sure, I disabled the compare and branch that detects pass/fail so that it always (pretends) to fail and the listed read from RAM matches the data that was written.

That's great to hear! I remember reading about trying dif settings for the Clk edge and the idle state for a intermittent EEPROM problem, but seeing how your code seemed to work with the '256. Well I guess there is a subtle difference between these SRAM families. Learn something new everyday!

Next stage is now working: 2 x 23LC1024 SPI SRAMs each operating from it's own SPI interface. The driver starts both (with DMA) at nearly the same time so they operate mostly in parallel. This allows 16 bit transfers in the same time it takes to do 8 bits. Both channels are running at 10 megabits per second (the max for dsPIC33F).

My initial attempts were troubled by an inability to use pin 22 (RP11) for SDO. It simply would not toggle. I've still got to research why that happened, but I found that using pin 23 (RP12) worked just fine. I then tried RP11 again with a brand new dsPIC33F IC and the results were the same - no toggling of SDO when assigned to RP11. This tells me that there is something funky about my peripheral device setup code. However, for the time being, it is working. I have a random data diagnostic running in 16 bit mode now._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

Very interesting idea. Could be very useful to hold L & R sample data and not have to worry about interleaving the data in one buffer.
On the board I've been building, I added another dip for a SPI EPROM but its on the same channel as the SRAM. So there's not any saving as to bandwidth, but I thought it would be useful for patch storage and recall.
I saw a project where the dsPIC was interfacing to a unusual CD filter chip, don't recall all the details, but he needed to run 2 SPI channels in synchronous, I think for left and right sample streams. He setup one SPI channel as a Master and the second in slave mode. Then ran a jumper from the master's SCLK out pin to the slave's SCLK in pin, so the master channel's CLK was in effect timing the whole system. Don't think this could be of help here, but it may be a way to trigger the second DMA channel start-up.
The 28 pin package is getting very tight, pin wise. If the duel SRAM setup is a big benefit I could re-route the 2nd dip's wiring to setup a second SPI channel, but lose either balanced DAC outputs or some Analog inputs? But I've got a 'gp708 protoboard with a TI 'aic23b codex that has an abundance of pins! On the one hand the '802 with the built-in DAC is very simple and fun; on the other hand, the larger dsPIC package opens new doors, (been thinking about the PMP interface with a large parallel RAM) but then the system complexity grows so fast!!
As I write this, a thought just occurred to me, Can the DMA controller run two channels simultaneously? If you have two SPI channels started at about the same time, will they both compleat at the same time, or will one DMA channel block the other? Don't remember reading anything about this one way or the other. My impression was that the DMA controller has a separate bus (from the CPU's) for the transfers but all DMA channels would need to share this bus.

I'm using 4 DMA channels to do this. Channel 0 has hard wired priority in terms of owning the bus. Yeah, all the DMA channels share the same SRAM port, but since the DMA is started sequentially, there doesn't seem to be an arbitration problem (that is, the data is not late enough to cause problems with the diagnostic). I was able to do this with one interrupt from the second read channel started. Read always finishes after write, so the DMA read interrupt from the second read channel started tells the program that all SPI DMA is complete.

The messy part is the amount of code needed to stuff the DMA write buffers before starting the transfer. If the SPI SRAM addresses are truly random, some 24 or so instructions are needed to fire off an SPI SRAM transaction. This is about 0.6 microseconds (assuming 40 MIPS). However, the rest happens in the DMA controller and the CPU can go do other things until the interrupt occurs. So it's not super efficient as parallel SRAM would be, but the DMA does help quite a bit.

Each SPI SRAM transaction needs 40 clocks, so at 10 megabits per second, this is 4 microseconds. In my case, since I use two in parallel, I get one 16 bit word transfer every 4 microseconds or 250,000 times per second. Doing a read and a write as are needed for echo means 125,000 echo samples per second (mono) or 62,500 per second in stereo. That's why I decided to try running two parallel SPI interfaces.

It does, as you say, use a lot of pins. I'm now working on adding a CS4270 codec IC which will need 6 (maybe 7) pins, but then I won't use the internal stereo DAC. So pins are tight, but for what I'm trying to do, the 28 pin package might work. I do save one pin by operating both SPI SRAM CS pins from a single dsPIC pin._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

Each SPI SRAM transaction needs 40 clocks, so at 10 megabits per second, this is 4 microseconds. In my case, since I use two in parallel, I get one 16 bit word transfer every 4 microseconds or 250,000 times per second. Doing a read and a write as are needed for echo means 125,000 echo samples per second (mono) or 62,500 per second in stereo. That's why I decided to try running two parallel SPI interfaces..

OK, I think I'm understanding. In effect, the SPI peripheral is the bottleneck, with each DMA channel spending most of the time waiting on the service request. Any DMA blocking that may occur, if the two SPI channels send DMA requests at the same time, is minimal compared to the time to transmit a byte.
When reading the DS for the LC1024s, it mentioned the dual and quad SPI modes, though, I'm thinking that the dsPIC' SPI channels don't allow this (no mention of it in that DS). I'm assuming those modes are similar to what you have created.

yeah, correct - no quad or double speed SPI modes for dsPIC33F. Heck, I wish they had a version (or a selectable mode using pin 3) that would access 16 bits per transfer instead of 8 bits._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

After reading Wikipedia; really only the quad mode would be a help. Both are half duplex modes, so dual mode runs at about the same speed as generic SPI full duplex and Quad mode offers about double the through-put. It's all mote anyway, never seen a SPI peri. on a uC that supported these modes, might be useful on an FPGA.
Oh Well

I've found the problem with RP11. It's I/O pin is output enabled using RPOR5. This register also enables RP10. There is a tremendous advantage for doing hardware device setup in C since the "bits" variables are affected as bit fields and not as full registers.

One way around this when using ASM30 is to use only BCLR and BSET instructions to change settings in such registers that are shared by more than one peripheral._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

Good to hear you resolved the problem with RP11. Will keep this in mind.

JovianPyx wrote:

...Heck, I wish they had a version (or a selectable mode using pin 3) that would access 16 bits per transfer instead of 8 bits.

This got me thinking; the SPI can handle word transfers, and the SRAM can be set for sequential mode, would that be any help? Not clear from the timing diag how the SRAM will react to a pause on the clock between word transfers, but it looks like it may work, as long as CS remains low. It might decrease the loading on the DMA controller. Would have to be mindful of rollover at the end of the array, but that may not be a concern for a circular buffer with a echo.

I had wondered that too. Now that you mentioned it, I looked at the timing diagram and it shows an address being sent to the SRAM. The PDF also says that in sequential mode, the SRAM ignores page boundaries. All that is needed to cut off the transaction after reading 2 or however many bytes is to raise bar-CS. I will have to try this today. The arithmetic says that two 16 bit words can be transfered 156,250 times per second. Doing a stereo read and write could happen 78,125 times per second, well fast enough to use a single SPI interface. A dual parallel interface could operate at twice that speed. This might actually simplify the driver code as well.

I will post if/when I get it working.

EDIT ADD: It turns out that I've been using sequential mode to read and write bytes all along. The default mode is sequential and I never sent a "byte mode" command to the control register. So sequential mode for reading and writing bytes has already been tested. The code I have reads or writes a byte and then raises bar-CS. All I need do is extend this to 16 bits._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessimaLast edited by JovianPyx on Sat Feb 02, 2013 11:06 am; edited 2 times in total

I just want to say thanks for creating this thread. I had an FPGA design where I needed about 1 Mbit of low-bandwidth external RAM but only had a few pins to spare. Serial RAM was a perfect fit. I just got the 1 Mbit Microchip part running last night, and it's working great.

The latest is I've reverted back to using two 23LC1024 SRAM ICs on one SPI bus because I needed a couple of pins for something else. Using sequential mode, I am transferring 32 bits of data per transfer and it is still faster than the 48 khz sample rate I will be using.

In an FPGA, you could use the quad speed mode that the 23LC1024 supports and do things quite a bit faster.

I've used the 23K256 IC (256kbits or 32kbytes) on an FPGA, I'd like to try the 23LC1024, especially in quad speed mode when I get a new supply of round tuits..._________________FPGA, dsPIC and Fatman Synth Stuff

Time flies like a banana.Fruit flies when you're having fun.BTW, Do these genes make my ass look fat?corruptio optimi pessima

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.