SPI doesnt indicate received byte

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

As far as i understand, the SPI is receiving a byte everytime i send one.

So this funtion should work:

unsigned char CSDC::CSPI::Receive(unsigned char dout)
{
	if (!initialized) return 0xff;
	AVR32_SPI.tdr = (unsigned int)dout;
	while ((AVR32_SPI.sr & (AVR32_SPI_SR_RDRF_MASK | AVR32_SPI_SR_TDRE_MASK)) !=
		   (AVR32_SPI_SR_RDRF_MASK | AVR32_SPI_SR_TDRE_MASK));
	return AVR32_SPI.rdr;
}

As you can see, i wait for the finished transmissin and the received byte.

But now, i am experiencing strange behavior:
The while-loop doesnt end! How is this possible?
Debugging shows, that one of the 2 checked bits do not become '1'. (Mostly the RDRF-bit)
SPI is initialized correctly. This routine works a lot of times until it stucks.

Can someone explain how it is possible to send a byte without receiving one?

Please help :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check the ovres (overrun bit) too. I believe that bit is set (and not the other you are polling) if you start master transfer without reading a waiting char.

Perhaps you should poll the two bits before sending as well as after. Or just read the rdr before send&receive.

Framework has one funk. for send and another for receive. Try them in that order. Or the opposite :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your opinion. I will check this issue again, when it is on its turn again ;-)
Currently i am hunting small bugs in every part of my software. So far it is working on lower speed. So this error has no high priority.
I will inform you later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, i have investigated a bit ;-)

Problem was debugging, that showed me wroing values and overrun breakpoints due to inlining. So i stopped in an endless loop where the function was inlines and no breakpoint was applicable. With instructionstepMode i get the correct results.

Reason why i stuck is this loop was, that i have 2 CLK-Drivers on the ClK-Line that are coordinated by software so that the should not interfear.
... should.
Both drivers where on at the same time to Clocksignal hangs around VCC.. hehe.

nteresting result: Ap7000 GPIO is stronger than UC3B peripherial driver. Maybe the UC3B-CLK-Signal has a higher resistance to avoid overshots..

Thanks so far ;-)