Garbage byte on first spi rx after power up

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable
        Hi, I have the PSoC 3 set up as an SPI slave communicating with another microcontroller. Right now I am just working on getting basic comms going, so I have the master sending 1 byte of data over and over every second. I print the values that are received by the PSoC over the serial wire viewer. The byte I send across seems to come across fine once it gets going, or if I stop and then start the master again without removing power. But if I remove power from the master and slave, I am always reading 0x73 as the first byte, all the other bytes that come through are OK. I have tried several different bytes to send, all have 0x73 as the first byte. Has anyone seen anything like this before? Is there some initialization I am missing on my PSoC? Code below. Thanks SPIS_Start(); while(1) { rxData = 0x01; if(SPIS_GetRxBufferSize() != 0) { rxData = SPIS_ReadRxData(); printf("0x%x\r\n", rxData); } }   
0 Likes
11 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

This is something inherent to SPI:

   

When you send a byte from master to slave, then with every bit sent you get one bit back. So it is quite clear, that the first byte answered must be a garbage byte, since the slave does not know yet what to answer. So best practice is to

   
        
  • Send the first (command) byte
  •     
  • Wait until transmitted completely
  •     
  • Clear the receive buffer
  •     
  • Transmit dummy bytes to receive wanted data.
  •    
   

 

   

Bob

0 Likes
Anonymous
Not applicable
        Hi Bob, Thanks for your response. I may have been unclear, or perhaps I'm not understanding. The master is sending one byte of data to the slave (PSoC3), and does not care about the response. So the master is clocking out 1 byte, which should then be clocked in to the PSoC RX buffer. I am doing this transaction repeatedly, but each instance is a separate transaction (chip select is going high between each byte sent from the master). I don't care (at the moment) about data from the slave to the master, I only care about data getting from the master to the slave. Again, I only see garbage byte on the first transaction after power up, and don't see it again after that. Thanks, David   
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Can you post your complete project, so that we all can have a look at all of your settings? To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.



Bob
 

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable
        The file should be attached. Thanks   
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

What about inserting a SPIS_ClearRxBuffer() just after the initialization. This ensures that the garbage byte is not sent by the master.

   

 

   

Bob

0 Likes
Anonymous
Not applicable
        That was my first thought as well, but it doesn't change the behavior.   
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Then you may take it proved that the master is sending a garbage byte. Check with a logic analyzer.

   

 Workaround: Threw away first byte received from master.

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable
        I don't think there is garbage coming from the master. I attached a scope shot for the MOSI pin at the PSoC. All the data shows as 0xAA, not the 0x73 that I first see come through. Also, I have used the master with other spi devices (it has multiple spi ports) and have not had this issue going to any other device.   
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Without seeing the clock and ss your shown signals are meaningless for me. I cannot see if that shows 0xaa or something else.

   

 

   

Bob

0 Likes
Anonymous
Not applicable
        With the clock, chip select and mosi pins next to each other, and since I have to manually hold the scope probes, it is impossible for me to capture all of them at once, I'd short something. Even without the clock and chip select, two things are clear. First, the data coming in to the PSoC is the same on the first transaction as it is for every other transaction. Second, it is clear that the data for the first transaction is not 0x73...the scope shot clearly shows an alternating bit pattern.   
0 Likes
ETRO_SSN583
Level 9
Level 9
100 sign-ins 5 likes given 1000 replies posted

Just an FYI, this is a cheap pretty good logic analyzer, I have 2

   

of them, they work great. Several vendors on ebay selling them.

   

 

   

www.ebay.com/itm/24MHz-8-Channel-USB-Logic-Analyzer-and-Decoder-USB-FPGA-I2C-UART-SPI-AVR-/141662645...

   

 

   

You get the SW here -

   

 

   

www.saleae.com/downloads

   

 

   

Regards, Dana.

0 Likes