SPI rx problem

RE: SPI rx problem

zhouyu — Wed, 28 Dec 2016 02:10:30 GMT

I got it. That is because I set #define SPI0_USE_EASY_DMA 1, although I don't understand why.

RE: SPI rx problem

zhouyu — Tue, 27 Dec 2016 07:52:29 GMT

It seems that sdk11 and sdk12 runs in a little bit different way. Getting flash id in sdk11


static uint8_t flash_get_id(uint8_t *manufacturer_id, uint16_t *device_id)
{
  uint8_t tx_buf[5], rx_buf[5];
  tx_buf[0] = W25Q_JEDEC_ID;
  ACCESS_FLASH_DATA(tx_buf, rx_buf, 5); 
  app_trace_log("[FLASH]%x %x %x %x %x\r\n", rx_buf[0], rx_buf[1], rx_buf[2],rx_buf[3], rx_buf[4]);
  *manufacturer_id = rx_buf[1];
  *device_id = ((uint16_t)rx_buf[2] <

The output of rx_buf is "[FLASH]ff ef 40 14 0"

But in SDK12


static uint8_t flash_get_id(uint8_t *manufacturer_id, uint16_t *device_id)
{
  uint8_t tx_buf[5], rx_buf[5];
  tx_buf[0] = W25Q_JEDEC_ID;
  ACCESS_FLASH_DATA(tx_buf, rx_buf, 5); 
  *manufacturer_id = rx_buf[2];
  *device_id = ((uint16_t)rx_buf[3] <

The output of rx_buf is "INFO:[FLASH]ff ff ef 40 14"

RE: SPI rx problem

kreis — Thu, 13 Oct 2016 20:31:14 GMT

Ok, thank you!

RE: SPI rx problem

RK — Thu, 13 Oct 2016 15:25:29 GMT

That's the whole point, the RX buffer IS receiving whilst the bytes are being sent. So you get dummy bytes in the buffer. SPI is a bi-directional protocol, one byte in for every byte out.

You haven't checked well enough on the forum, this has been discussed a number of times.

RE: SPI rx problem

kreis — Thu, 13 Oct 2016 14:30:23 GMT

Hi RK, thank you very much for answering. I still think that there's something strange about it because I had implemented the same memory on another platform (ARM cortex-M3) and I didn't receive those dummy packages on my rx buffer. Besides I've checked on the forum here for other users examples and from the ones who printed the received buffer I couldn't find the dummy bytes. It seems that the rx buffer is also reading while the bytes are being send.

Thank you for your help.

RE: SPI rx problem

RK — Tue, 11 Oct 2016 23:45:22 GMT

That's how SPI works, it's a synchronous read-write protocol, one byte goes out and another byte comes in at the same time. So of course you are going to get extra bytes on the start of the received data because something has to come in whilst the command is going out and only at the next clock can the chip respond with the answer, once it's seen the command.

Did you notice that the number of dummy bytes you get at the start of the received message is the same as the number of bytes on the command you clocked out? That should have given you a clue what is going on.

I suggest you find a description of the SPI protocol online and read it to understand what it's doing.