• State
  • Locked Locked
  • Replies 0 replies
  • Subscribers 81 subscribers
  • Views 407 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SPI hangs after rapid writes to TX buffer

Alfred Bos
Prodigy 30 points

Hi,

I've got an issue that might be related to me :)...but I'd like some other opions/confirmations.

I'm doing some SPI communication between two 28069's. Upto 700Khz it worked great. After I tested it on the final hardware it turns out that above 700 Khz it doesn't work anymore. At first I blamed the hardware...of course :D.

But it turns out my software is behaving strange. I've found out that the nSlaveSelect isn't correctly generated  (constantly low) but the slave received the data by accident correctly..as expected; so that's way I hadn't notices this before.

Anyway, by suspending the execution and continuing, suddenly the correct !SS signal IS generated. Basically the problem accurs when I do two consecutive writes to the TX buffer in succession (two lines)...this leads to no nSS signal being generated by the controller.

Also, this suspend-continue thing only works if it is specified that the SPI hardware should keep going (FREE = 1). It looks like that the whole transfer continues and this causes the processor the be able to accept more new bytes . Basically what I would like to know:

1. Why is there nog longer a !SS generated by the processor once two consecutive writes have occured ?

2. How can I detect such a problem before sending new data, I'm not clear whether TXBUFFFULL helps ?

I've attached a image from the logicanalyzer, so you see the last correct bytes; but than I transmit 2 bytes in rapid succesion...and this 'kills' the SPI !

 

So any help/suggestion/explaination is welcome.

Alfred.

 

[UPDATE]

I've tested what BUFFULL flag does when I write, after the 2nd byte is written it goes from 0 to 1. But this is too late, after this nog longer a slave-select signal is generated.