MiBSPI + 23lc0124 SRAM

i went through some of the posts and i ve tried a code.

while reading the data if i use  mibspiGetData(),  received data = 0x00 and flags = 0x00

if i use rx[1].data and rx[1].flags , received data = 0x00 and flags = 0x0D

which should i use?  i m using TG0 for txn and TG1 for reception. length of the buffers is 1.

have i configured correctly..  i am attaching the code.

please say me where i go wrong and how to correct that.

thanks

3731.mibspi_sram.zip

i tried to use mibspiSetData() function. but it is configured only for data field.

i have to use CSHOLD option to keep the chip select at active low during entire transmission. so i configured TG0 with CSHOLD ENABLED & TG1 with CSHOLD DISABLED.

even then its not working. how to use  that feature? i think if i use that properly it ll work

3225.mibspi_sram_trial1.zip

I tried in both the ways.
i used halcogen generated functions and also i tried with directly loading RAM.
i read either 00 or FF....
but inRXRAM flags it is 0xAD....
A= RXEMPTY & TXFULL.
how to clear this??????

anyone pls help me

Hi Pavithra,

Trying to get 'my head around' the problem. So you're working on talking to a microchip 23lc1024 ?

For these functions:
SRAMWriteStatusReg();
SRAMReadStatusReg();

SRAMWriteByte(Address,DATA);

rx_data=SRAMReadByte(Address);

For example, I'm thinking that for your function SRAMReadStatusReg() you want to have the MibSPI perform what you see in the Microchip diagram Figure 2.7 READ MODE REGISTER TIMING SEQUENCE (RMDR) ?

And for SRAMReadByte(Address) are you trying to implement the diagram Figure 2.1 BYTE READ SEQUENCE (SPI MODE)?

If that's the general idea, then where exactly are you running into trouble, and what do you see when it fails (on the pins would be good to know as well as the register) ... i.e. if you marked up these diagrams of sequences, how far along do you get before getting stuck.

For each of these sequences, I think you could setup one transfer group and then trigger that group with a software trigger.

I opened the HalCoGen file you sent, and I see that two of the transfer groups are setup for length of 1, using data format 0 (8 bits charlen).

Now, taking the diagram Figure 2.1 BYTE READ SEQUENCE (SPI MODE) I break this down as a transfer of 5 bytes.
For the 1st 4 bytes, you want to transmit 0x03, ADDR[23:16], ADDR[15:8] and ADDR[7:0] but you don't care about the data received.
And for the 5th byte you can transmit anything (don't care so maybe pick 0's) and on this byte you care about the data that you receive.

I would have set up this as a transfer group that uses a length = 5 because there are 5 bytes to transfer.

For these 5 buffer entries you have 5 locations in TXRAM and 5 in RXRAM. These locations are 32-bits wide, the upper 16 bits are control and the lower 16 bits are data.

So start with the TXRAM, and just consider the data. You would write 0x03, ADDR[23:16], ADDR[15:8] and ADDR[7:0], plus 0x00 (don't care) to the lower 8 bits of each of the TXRAM's TXDATA field entries. Pretty simple right - you're putting the whole message sequence there and now you just need the MibSPI to execute it.

Ok now come the control fields. The control field for the TXRAM is BUFMODE, CSHOLD, LOCK, WDEL, and CSNR. (See 21.9.3 of the TRM).

CSNR is simply set to the chip select that you want active. So assume chip select SCS[0] - you would set CSNR to 0xFE (although it may not read back that way since not all chip selects are available).

DFSEL you should write as '0' since you want data format 0 (8 bit char like you setup in HalCoGen.

WDEL kind of depends on the timings - I'd just set it to '1' to start with and see if you can remove it later.

For LOCK, you can probably set to '0' as long as you are not initiating more than one transfer at a time. And it's probably best to do this as we've had trouble w. LOCK + CSHOLD in DMA mode with other customers (posts on forum about this and I think an errata too..)

For CSHOLD you want to set this to '1' for the first four buffers and to '0' on the last buffer - since you want to release the chip select after that transfer.

Finally comes the BUFMODE. I would start with 7 myself, although this will make you have to read back all 5 data words received even though you only care about the last one. Anyway start with this and later you could try letting the first 4 words repeat even if they will have a receive overrun (BUFMODE = 5). You could also even consider that the command (0x03) doesn't need to be updated again, just the address, so you could use BUFMODE=4 for it. Anyway, start with 7 until you get a feel for how this works.

You should be able to setup the buffers this way, and then initiate a transfer by triggering the transfer group through software. This should make the five bytes transfer immediately on the SPI like the diagram shows. You can check the RXRAM to see what happened.
If you think about the upper 16 bits of the TXRAM as 'Control' for each byte of the transfer sequence, then the upper 16 bits of RXRAM can be though of as the "Status" register for each byte of the transfer. You should see RXEMPTY change to '0' once the transfer has been completed.

Now since you are in BUFMODE 7 (assuming you start there) then before you repeat the sequence you will have to re-write all of the lower 16 bit data words for each of the transmit buffers (in TXRAM) and read all of the 16 lower bit data words of the receive buffers (in RXRAM) just like the were 5 separate SPIDAT / SPIBUF registers ... and then you'll be able to start another transfer. If you don't do this then when you get to a buffer that's not ready the MIBSPI will suspend there and wait until it is ready.

This is where you might later optimize by changing the buffer mode, again the only data you really want to read is from the 5th copy of "SPIBUF" (the 5th word of the TG RXRAM). and you don't care if you got 'receive overruns' on the first four data words since the SPI serial flash wasn't sending you anything interesting there.

Hopefully that spawns some ideas. I am not sure that you will be able to use HalCoGen's APIs directly, you might need to make a custom version that configures the transfer groups as I describe or as you wind up deciding. But you can certainly try this through HalCoGen by setting length = 5 and then seeing how close you come. (inspect the TXRAM and RXRAM in the memory window of CCS for example, to see how the buffers get configured).

Keep me posted on how this goes for you.

hi Anthony Seely,

thanks for your reply.
i already changed that transfer group length as 5.
now i ll try with buffer mode.
i ll update after working with that.

regards
pavithra

hi sir!!

i tried as u said.

after reading the data the control transfers to prefetch entry. i tried with both buffer mode = 4 and 7

i m attaching the snap shots and my code. say me where i go wrong.

6735.MIBSPI_123.zip

looking forward for help.

thanks

uint8 SRAMReadByte()

{

uint8 dummy3;

mibspiSetData(mibspiREG1, 3, read_byte);

mibspiTransfer(mibspiREG1, 3);

while(!(mibspiIsTransferComplete(mibspiREG1, 3)));

mibspiREG1->TGINTFLG = 0x00080000; // clear the flag

while ((RAM->rx[4].flags & 0x8000) == 0x8000);

mibspiGetData(mibspiREG1, 3, &dummy3);

mibspiREG1->TGINTFLG = 0x00080000; // clear the flag

return dummy3;

}

i checked for RXEMPTY = 0. my program halts here... controller dint receive anything i think.

thanks

Pavithra,

Ok I tried the code that you sent on a launchpad w. an oscilloscope attached.

I did wind up rebuilding the project  (I just did a 'debug as' but this triggered a rebuild..)

I'm seeing a few things:

 1) on the oscilloscope, for the function calls SRAMWriteStatusReg() and SRAMReadStatusReg()  I can see that the chip select is going high between the two bytes in each transfer.   This probably won't work well w. the device that you are trying to talk to ... I think it wants the chip select held for both bytes.

2) there is probably a pointer related problem somewhere in the function call   mibspiGetData(mibspiREG1, 3, &dummy3);

    (so in the mibspiGetData function).    Maybe you have the size of dummy 3 set too small for the size of the transfer group.

   I think probably you need to define an array of 5 elements and pass the pointer to this array to mibspiGetData.

   Then return just the last element to the calling function.

   Or write your own version of 'mibspGetData' that just reads one word from the MibSPI.

    Since you pass the address of a single uint8 but the function thinks it's an array of length matching the transfer group size (5 I think)

    what it's going to do is write over the uint8 and past it in memory.     Since this uint8  'dummy_3' is a local variable in SRAMReadByte() it's on the stack, and when the call to mibspiGetData is done the stack is corrupt.   So return dummy3 lands you at a prefetch abort.

See below - you can see how the call stack no longer traces back to main() once mibspiGetData() has executed:

Before this function is called it looks correct, like this: 

thank u sir...
prefetch entry problem got cleared now.
but i receive only 0xFF.

totally i use 14 buffers. i m checking rx[13].flags for RXEMPTY. is that correct? y it is always receiving 0xff???
i m still trying to make it work. if i make any changes i ll update it.

thanks.

Pavithra,

What would be helpful is to make a table something like this:


TG BUF MESSAGE MESSAGE
# # TYPE BYTE

and then fill it in, with the information related to the serial memory that you are trying to talk to.
So I think probably your first few rows are going to be related to the status messages..

that would help me to answer on questions like rx[13].flags for RXEMPTY but then more importantly we can work on
adding some columns that show what the appropriate control bits should be for each transmit buffer and which
receive buffer status are the ones that you need to wait on / clear.

EDIT: also note that I saw you had the CS high between bytes of your status messages.  This could be causing problems when actually communicating with the memory so you want to also look at the clock and chip select (and somi/simo) with a scope or logic analyzer or bus sniffer if you can.

thank you sir!

while working with SPI i dint enable CSHOLD for SRAMWriteStatusReg() and SRAMReadStatusReg().

i followed the same with MIBSPI. i dont know why it dint work

i have made a table and i m attaching that excel sheet. i m using chip select 1.

please look into it and say me what are the corrections.

3443.table.xlsx

Hi Pavithra,

Your table looks good so far. The next thing that you might add are the exact settings for the upper 16 bits of each buffer,
but overall the strategy looks ok. Looks like you're setting it up for byte reads and writes which is probably the right place to start.

Is it possible that the read instruction and write instruction values are reversed?
The microchip datasheet that I'm looking at shows that the READ instruction value is 0x03 (instead of 0x02)
and WRITE is 0x02 (instead of 0x03).

Best Regards,
Anthony

thanks sir!!

i get the output lik dis.
input = 0x0b ; output = 0x0b
input = 0x1c ; output = 0x0e
input = 0x2f ; output = 0x2f
input = 0xaa ; output = ox55

so if LSB = 0, the output is right shifted by 1 bit
if LSB = 1, there is no change in output.

is there anything related to hardware connection?? it was mentioned in one of the posts.

pavithra,

hard to say from the description.   I don't really even know for sure where & how input and output are measured.

for example, are these values the ones that appear in the RAM of the MibSPI, or are you interpreting them by monitoring

the bus with a piece of test equipment.

I can't really think of anything that would cause a data dependency in the shift count, just due to a common software problem.

So I would probably start by looking at the actual clock and data signals with an oscilloscope.

I'd check the voltage levels (one possibllity for a data dependence) and also look for any coupling between the data and clock line.

And I'd double check the phase/polarity settings just to make sure they match.   But hard to explain a shift count that varies *only* with the LSB so it will be interesting to see what you find.