ASF - spi_write_packet error on lenght

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

Hi,
I'm using SPI from ASF and there is a problem on the function spi_write_packet. Per example:

spi_write_packet(&SPIC, data, 3);

it will send only 2 bytes and not 3.

spi_write_packet(&SPIC, data, 1);

it will send 1 byte but

spi_write_packet(&SPIC, data, 2);

also send only one byte :s

I checked it on the logic analyser after spend some time wondering why the radio transceiver was discard the packets because incorrect payload, the problem comes from this function that send one byte less that the one I pass as argument.

Do you have any idea why that happens?

This is how I'm using it:

void spi_write_multiple_teste(uint8_t * data, uint8_t len){

	struct spi_device spi_device_conf = {
		.id = IOPORT_CREATE_PIN(PORTR, 0)
	};

	spi_select_device(&SPIC, &spi_device_conf);
	spi_write_packet(&SPIC, data, 3);
	spi_deselect_device(&SPIC, &spi_device_conf);
}

I hardcoded the len value for debug purpose. You can see the attached image of this case.

Thank you

Attachment(s): 

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

AVR, Xmega, ARM, UC3?

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

clawson wrote:
AVR, Xmega, ARM, UC3?
Xmega 32E5. I was confused if I should post it here or in xmega forum :s

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

If I remember correctly from when I was using the ASF drivers for a TFT display via SPI, one has to wait for the last byte to have gone before deselecting. This is because the functions that send a single byte checks beforehand to see if the buffer is empty.
So I would try waiting for tx empty before de-asserting CS.
http://asf.atmel.com/docs/3.8.1/sam4s/html/spi_8h.html#a6ffd41921b3092e4a73f659f8ee37cdf

Having said this, your timing diagram does not readily support my theory, but it's the best answer so far!

Four legs good, two legs bad, three legs stable.

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

John_A_Brown wrote:
If I remember correctly from when I was using the ASF drivers for a TFT display via SPI, one has to wait for the last byte to have gone before deselecting. This is because the functions that send a single byte checks beforehand to see if the buffer is empty.
So I would try waiting for tx empty before de-asserting CS.
http://asf.atmel.com/docs/3.8.1/sam4s/html/spi_8h.html#a6ffd41921b3092e4a73f659f8ee37cdf

Having said this, your timing diagram does not readily support my theory, but it's the best answer so far!

I forgot to say that it isn't send the first byte of the buffer.

This is how I create the buffer to send. On the debug I confirm that the buffer was ok before call spi_write_multiple_teste.

void spi_write_cmd(uint8_t cmd, uint8_t * value, uint8_t len){
	
	uint8_t buffer[len+1];
	buffer[0] = (cmd);
	uint8_t i = 0;
	for(i=0;i
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sorry, but I do not understand what you are trying to say. Did you try what I suggested?

Four legs good, two legs bad, three legs stable.

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

sounds like a bug ? I am talking to a si4463 and use only the single byte spi send and repeat it as often as it is required which is why i havent seen the issue you describe. What rf chip are you using ?

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

Forgot to ask. What version of ASF are you using ?

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

John_A_Brown wrote:
I'm sorry, but I do not understand what you are trying to say. Did you try what I suggested?

You said me to wait a little more to see if there is another byte sent but my problem is the first byte from the buffer that isn't send.

For example:
uint8_t buffer[5] = {1,2,3,4,5};

it send the values 2,3,4,5 if len = 5 but if len=6 then it sends 2,3,4,5,X.

PS: sorry my english

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

Well I think you'll have to debug it yourself. Find the ASF library function and check out what's actually happening.

Four legs good, two legs bad, three legs stable.

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

Isn't it great that we have an ASF to deal with the extreme complicated stuff like the SPI....don't know how we all managed 30 years ago without it.. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Isn't it great that we have an ASF to deal with the extreme complicated stuff like the SPI....don't know how we all managed 30 years ago without it.. :?

I totally agree. I never used ASF before I started using the SAM4, which is slightly more complex than XMegas.

Four legs good, two legs bad, three legs stable.