In this case, I am trying to read the SIPR register (0x000F - 0x0012). Therefore, I am sending 4 bytes (2 for address and 2 for OP=0 and length)
Here, checking on the official w5200.h library from github, I can see that length is used to specify how many bytes I want to read. Therefore, in the case of the SIPR register I want to read 4 bytes. Is that correct?
What is the difference between nSS and nSCS? In the user manual states nSS for the pinout and nSCS for the SPI signals diagram. They refer to the same pin, right?
I have seen in this thread that nSS is driven to 0 and 1 on every byte rather than having it to 0 and sending all the bytes as shown in the datasheet.
There shouldn’t be any (if I am not mistaken):
SS = Slave Select
CS = Chip Select
n = Active Low, i. e. 0 means the function is enable/the chip is selected
This waveform looks a bit strange to me, kinda as if two devices are driving the same line; I’ve observed this with I²C devices, where this behavior is desired. It looks like one device is driving the line low, and then a second one joins in.
Could you maybe verify that all your host mcu’s gpio pins are correctly configured (especially that MISO is in high impedance/input mode) and that there isn’t any undesired physical connection between IO lines on your board?
I am not sure about the W5200, but the W5500 has two data transfer modes which can be selected individually with each transfert. Either 1, 2 or 4 byte fixed size transfer or a variable data length mode, where the beginning and the end of a frame is marked by the Chip Select going low at the start and high in the end.
Toggling CS (or SS for that matter) during a conversation would be very uncommon (and also isn’t done in the manual).
I am just not sure what they mean by “The MISO pin should
be selected by driving MISO low after the falling edge of the CSn.”.
Do you also send the dummy bytes to give the chip the possibility to transfer the requested data? Or do you only send the 4 instruction bytes? (Looks a bit like it on first glance)
@Philipp_K, thank you for taking the time to reply.
Chip Select: Then that is correct as I am running it with active low as the yellow curve shows.
The first attempt was to mimic the waveforms shown in the user manual (first two images from the original post) and the one from EDIT 1.
I can see an error there that there is no time between SS goes low and the first clock pulse on SCLK (as shown on the page 7 of the user manual).
I am doing all this on an FPGA and I have assigned MISO to be an input signal. I do not think that the long cables and everything wired on a breadboard should be an issue.
I have that “strange” looking waveforms because of this thread where apparently someone from WIZnet showed the device working with that so I do not know if I should follow the way the waveforms are in the manual or in that example where they show the device working.
I am also sending the data length. If we split the MOSI wavefor, it is 00 0F (address) and 0001. Then, the 5th 8 group of pulses on SCLK is for reading the data on MISO.
So, if I understand the manual correctly, I am sending 16 bits for address and 16 bits for OP and length. Then, I should generate the number of clock cycles accordingly to the length value (length x 8) and that is why, in this case that I want to read only one byte (address 0x000F) I am generating on SCLK 5 “packets” of 8 clock pulses.
Yes, that is what I meant by sending 5 packets of 8 clock pulses on SCLK. I am sending 4 bytes for address, OP and length and then I have one more byte (because I have length=1) then (with 0x00 rather than 0xFF) that the device should send back data.
Hi~aripod
The value of SIPR register is empty after reset operation or Initial version.
Therefore the value of SIPR register may not be.
I recommend reading W5200 version register(0x001F).
If you read version register(0x001F), you see the 0x03 through MISO.
The MOSI waveform looks good to me. nCS going high after every byte is still strange, since as you said, the manual doesn’t mention that, but states explicitly that nCS has to go low before the transmission and high afterwards (no word of in between). I can’t tell for sure, but I’d expect that the chip would understand this as an aborted transmission (though again, this is just a guess).
After initialisation, the register should read 0x00, which is what you receive here, but in your first picture without toggling nCS during transfer, you get 0xFF I can see it correctly.
Maybe we can get a closeup of that transmission, too, to see what happens there?
Otherwise I too would be curious if reading the version register works, as Irina suggested.
Also, is the level on the Reset line as expected? (Just a thought)
If both ways work for you, I would recommend doing it as described in the manual since I’d say that this is more logical from the interface point of view
What’s the difference between the above two picture?
I think the difference between the above two picture is the initial value of MISO.
I can’t confirm the MISO about Version register in first picture.
But I can confirm the MISO value about Version register in second picture.
It is correct as MISO value. MISO value saw the 0x03.
The issue with the first one, where MISO is always low is because nRESET was also low.
In the second one, MISO is 0x03 as expected but the question is if it is ok for MISO to be always high, comparing to the example cited on here where it is low.
This all is double odd because MISO must be tri-state when SS is high. When chip is in reset state, it must also keep MISO tri-state. Pull-down resistor on MISO line?
Well, your’re right of course, but he won’t be able to see the impedance of the MISO line in his logic analyzer, only the level it happens to have, which would be 0V if the line hasn’t been charged before
I went back to this project and I see that the pulses over MISO are out of sync with SCLK and their width is shorter than SCLK’s period. In this thread it is more clear. Any help will be much appreciated.
