Why does W6100 returns 1 2 3 as first three bytes during every read?

TCP/IP Chip W6100
#1

I am using io6Library to communicate with w6100 and when I do getSHAR(), etc. I always get 1 2 3 as first 3 bytes in the response. So the actual length of received data will be 3 + 6 in case of SHAR but io6Library only considers read len to be 6. what is this 1, 2, 3?

When I checked the sample codes, it doesn’t seem like other 1st 3 bytes (1,2,3) are handled in io6Library?

#2

Update: I found that the timing diagram also shows 1, 2, 3 in the in response. However, no further info is provided about what those bytes mean.

rsz_spi_read
rsz_spi_read901×378 99.5 KB

#3

This is a value to check if SPI Read is working properly.
As the value set by WIZnet, dummy data is generally entered, but it is fixed as 123.

#4

Then how do EVB test codes using io6Library work when these 1st 3 bytes are not handled by the library. I also didn’t see handling of 1st 3 bytes in SPI read/write methods of codes given by WIZnet. I referred to w6100-evb-gcc-eclipse and W6100EVB_CUBEIDE.

For my host controller, I have modified my SPI read/write methods to ignore these bytes. Am I missing anything? Is there a way to stop WIZnet from sending host controller 123?

Thanks!

#5

Then how do EVB test codes using io6Library work when these 1st 3 bytes are not handled by the library. I also didn’t see handling of 1st 3 bytes in SPI read/write methods of codes given by WIZnet. I referred to w6100-evb-gcc-eclipse and W6100EVB_CUBEIDE.

For my host controller, I have modified my SPI read/write methods to ignore these bytes. Am I missing anything? Is there a way to stop WIZnet from sending host controller 123?

Thanks!