News:

PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

SPI_24.inc and 23LC1024 issues

Started by Wimax, Sep 29, 2022, 03:39 PM

Previous topic - Next topic

Wimax

Hello Everybody !

I am experiencing a problem with the SPI24.inc library and a 23LC1024 RAM.
I use it to write in sequential mode many bytes, at the limit even the whole RAM, without any problem starting from the first address.
I then need to read blocks of N bytes, again in sequential mode for convenience and management efficiency, changing the initial read address each cycle.
Apart from the first read cycle of N bytes, which occurs correctly, the other read cycles do not provide correct results.
The initial addresses are provided as a 24-bit word divided into 3 separate bytes starting with the initial address 4261413119 in decimal (11111110000000000011111111 in binary) by transmitting the MSB first.
Any n-th address is calculated as 4261413119 + n*256.
Each read cycle begins with the command sequence:

adr=4261413119 ' adr is a Dword variable
 
Low CS_RAM
               
                SPI1_Write(0x03) ' Read command
            SPI1_Write(adr.Byte2)
                SPI1_Write(adr.Byte1)
                SPI1_Write(adr.Byte0)

 And then the actual read cycle:

                    For n=0 To 31 ' Read 32 bytes
                    FL=SPI1_Read()
                    Mr[n]=FL ' Store in Mr array
                    HRSOutLn Dec FL
                    Next

High CS_RAM

DelayMS 100

adr=4261413119+32*256 ' Calculate the second block initial address
 
Low CS_RAM
               
                SPI1_Write(0x03)
            SPI1_Write(adr.Byte2)
                SPI1_Write(adr.Byte1)
                SPI1_Write(adr.Byte0)

 And then the actual read cycle:

                    For n=0 To 31
                    FL=SPI1_Read()
                    Mr[n]=FL
                    HRSOutLn Dec FL
                    Next

High CS_RAM
on the second cycle I do not get the correct values, however, if I read the same number of total bytes in one sequential read there are no problem  :'(





Gamboa

Wimax,
I also found a problem with this library. I don't have a solution. I'm still using the old compiler version for this project.

https://protoncompiler.com/index.php/topic,933.0.html

Regards,
Gamboa
Long live for you

Wimax

Hi Gamboa,

I read your old post, I would say it is a "creepy" problem I went crazy trying to figure out if the problem was in the chip, but at this point I think there is something wrong with the library.
The fact that I don't have problems with address 0 or with totally sequential reads suggests that there is something wrong with the transmission of the 4 bytes at the beginning of each cycle (1 byte for the command and 3 bytes for the address).

Is the library you included in your post the old but working one ?


Les, can you help us solve the puzzle ?  :-\

Gamboa

Wimax,
I don't remember what I uploaded at the time. I believe that it is the library that I use and that it works with one version and not with another.

Regards,
Gamboa
Long live for you

Wimax

Taking for granted the perfection of Positron16 (largely well known by all of us users) I also stressed Microchip's support, a little hardware vs. software match !

I hope Les can help us solve the problem if indeed there is a bug in the latest SPI_24  :'(

Wimax

#5
Gamboa,

I have finally solved the arcane mystery !
I was wrong to trust what I found on the net, in fact the way of calculating the address on a decimal basis (taking into account the 7 most significant bits always at 1 as don't care) is wrong ! It is sufficient to consider, as initial address, 16646144 or 111111100000000000000000 in binary. It is then sufficient to send to the RAM, after the read command, the sequence Byte2, Byte1, Byte0 of the previous number. The next N-th address is calculated simply as 16646144+N  ;) . With a lot of patience, I have captured the signals on the bus by means of logic state analyzer, and there seem to be no anomalies on the bus.


tumbleweed

QuoteIt is sufficient to consider, as initial address, 16646144 or 111111100000000000000000 in binary.
It's a 128KB part, so just use addresses 0 to 131071 (0x00000 to 0x1FFFF) and set the don't care bits to 0.


Wimax

Yes, but some data-formatting is required as SPI packets are, usually, 8 bit wide.
Using decimal notation (hopefully correct  ;D ) is more convenient for me.

tumbleweed

My point is you can drop the whole '16646144+N' offset calculations for the address.
You can still work in decimal if you like and use addr = 0 to 131071

Wimax

Ok, directly defining the address as a dword, where unused bits are automatically zeros, and sending always to the RAM byte0, byte1 and byte2 in the right order ?

tumbleweed

Yup.

Send the addr bytes highest to lowest (byte2, byte1, byte0)

Wimax

I went around the world to go to the other side of the street  ;D

Thank you very much for the tip!  ;D