2830x SPI SPISTE

Justin Magyar

Hello All,

I have run into a bit of a problem with trying to get the /SPITE pin to do what I would like. I am using a SPI EEPROM that requires the CS pin (which is connected to /SPITE) goes low for each 8 bytes, then high again briefly before going low for the next 8 bytes. For instance, I need to send a Read_Status opcode, then have the CS go high, then low again for a Read opcode. However, if I have set the transmit buff to a value, then check the buffer full pin, and set the transmit buffer to the next value the CS pin stays low the whole time. However, if I only send one command one time then the CS pin comes back up right after that command.

The following code gives the screen capture below, the CS pin needs to come high after the op-code and then back low to transmit the dummy data:

if(eeprom.isTest == FALSE)
{
     TRANSMIT_DATA_REGISTER = READ_STATUS_OPCODE;

     while(COMMUNICATIONS_FLAG && (uwMicroTimeoutCounter < EEPROM_WRITE_TIMEOUT))
        {
            uwMicroTimeoutCounter++;

            //Set global register to 1 to indicate micro timeout
            if(uwMicroTimeoutCounter >= EEPROM_WRITE_TIMEOUT)
            {
                isEEPROMTimeout = TRUE;
                eeprom.outputs.ubEEPROMTimeoutRegister = eeprom.outputs.ubEEPROMTimeoutRegister | 0x01;
            }
        }
        uwMicroTimeoutCounter = 0;

        //Send dummy data to the EEPROM to get the status back
        TRANSMIT_DATA_REGISTER = 0x0000;
}
eeprom.isTest=TRUE;

Orange is the CS pin, Blue is SPICLK, Purple is transmit data from the micro (opcode 00000101, then 00000000)

If I remove the dummy data send then CS pin does come high right after sending the read status opcode.

I know the 2803x datasheet says: "In the master mode, SPISTE goes active 0.5tc(SPC) (minimum) before valid SPI clock edge. On the trailing
end of the word, the SPISTE will go inactive 0.5tc(SPC) after the receiving edge (SPICLK) of the last data bit,
except that SPISTE stays active between back-to-back transmit words in both FIFO and non-FIFO modes." but I'm essentially looking for a way around this functionality. Hardcoding the CS pin as a GPIO isnt hard and I did on a different processor with this same EEPROM, I'm just trying to use the micro's functionality to its fullest.

Thanks,

Justin

over 14 years ago

0 Daniel Chang over 14 years ago

TI__Expert 4120 points

Justin,

I don't think you can change the way the SPISTE pin works. Your easiest option might be to use a GPIO pin instead.

Regards,
Daniel

0 Santosh Athuru over 14 years ago in reply to Daniel Chang

TI__Mastermind 19810 points

yeah, you need to configure the SPISTE pin as a GPIO and pull it LOW before you send data and keep it low how lever ong you want it to to be low.

we do the same thing in SPI Master mode boot ROM, which works with SPI EEPROMs.

Best REgards

Santosh

0 Justin Magyar over 14 years ago in reply to Daniel Chang

Prodigy 70 points

Hi Daniel and Santosh,

Thanks for the replies. It's interesting that if you wait long enough the SPISTE pin goes back high, but if in the software you have the buffer loaded fairly quickly again like the example I gave, it never does. Do you have any idea how long or what is the trigger for the pin to return high? I was also thinking about seeing if I can read the SPISTE line like an output (even though it is configured as SPISTE obviously) and then in the wait loop maybe wait for that to go high, instead of checking if the transmit buffer is empty.

GPIO is definitely the fallback plan, I was just trying to use the processor functionality. Sounds like that's the direction I have to go which is easy enough.

Thanks!

Justin

0 Daniel Chang over 14 years ago in reply to Justin Magyar

TI__Expert 4120 points

I am not 100% sure but I believe you can check the GPIO DAT regs for the current state of the pin.

0 Justin Magyar over 14 years ago in reply to Daniel Chang

Prodigy 70 points

I just wanted to reply to say thanks and incase anyone searches on this in the future. Using the pin as a GPIO works of course, but you can read the /SPISTE pin as an input even though it's configured to be /SPISTE. Just add a NOP or two for timing purposes (the CS pin might not have had enough time to go low without them) then in the while loop I posted above check for the pin to go back high instead of the send buffer. Works great.

0 Mauricio Guevara over 13 years ago in reply to Justin Magyar

Prodigy 60 points

Hi all,

I'm running into pretty much the same problem that Justin was...

I'm using the 28335

I also need to write to flash mem, the process to write is as folows, the 28335 has to:

1) CS Low

2) send 1-byte Instruction_code (write SPITXBUF)

3) receive data (read SPIRXBUF. Since it reads the whole mem in one shot I have to loop this several times)

4) CS Low (again to start write)

5) CS High (to stop reading)

In step 3, if I read for too longthe TXBUFF is empty and stops the clock breaking the read sequence, how can I send dummy data to keep the clk running non-stop and being able to read the RXBUF without interrupting the TXBUF.

any help is appreciated,

thanks,

Mauricio

0 Francois Beaucamp over 12 years ago in reply to Mauricio Guevara

Intellectual 400 points

Hello,

I have somehow the same problem : I have connected a fast 2 channels SPI DAC converter (mcp4822) to 28035.

The DAC requires 2 low pulses on the CS (connected to SPISTE), one with the value of the first DAC value, the second

with the other DAC value.

The problem is that when I put the two vales in the TX fifo, I have only one long low CS pulse, which is not correct.

I've tried to put the second value in a SPI isr but this is the same, only one low cs pulse.

My question is :

is there an automatic solution for driving the SPISTE low the high at each word send on the SPI ?

I prefer not to have to drive this pin manually.

Best regards

fran cois

C2000™︎ microcontrollers

C2000 microcontrollers forum

2830x SPI SPISTE