At first, thank you very much for the reply! You have been extremely helpful.
You are right: If I can’t get the correct value with one read access, I could eventually live with the safe value. This could have a great disadvantage, though:
Suppose the the upper byte is 0, the lower byte is 255. While reading the upper byte, the lower byte counts up and thus becomes 0 (plus carry which is now in the upper byte which I won’t notice because I already have read it). Reading the lower byte yields 0 then, so I have read (upper byte = 0) and (lower byte = 0).
Or course, this is safe in the sense that I won’t overrun the buffer when reading the data, even though the value is not correct, i.e. I won’t screw the registers. But it will make me believe that 0 bytes have arrived although actually 256 bytes have arrived. If such a situation happens multiple times, it could lead to unforeseen problems (due to the internal structure of our software).
I know that issue (8-bit interface with 16-bit values) from other hardware devices. On other devices, this is solved the following way: The lower byte is not read from the current live value, but from a buffer. In the same moment when the upper byte is read (from the current live value), the current live lower byte is latched (by hardware) into a (one-byte) buffer which is independent from the current live value and thus keeps the latched value forever (well, until the next reading of the upper byte). Reading the lower byte then always reads the buffer (and not the current live lower byte).
Of course, you could do that vice versa as well (roles of upper byte and lower byte exchanged). In any case, that way you always get a two-byte value which is guaranteed to be up-to-date and atomically correct even if the value is read using an 8-bit bus.
From the datasheet, I got the impression that the w5200 implements exactly the method described above. After all, there is no hint in the datasheet that reading the upper byte first and the lower byte later returns only a “safe” value. Quite the contrary, the final part of the section I cited in my initial post reads “[…] to get the correct value.” (emphasis mine). That made me believe that -like on other devices- reading the upper byte freezes the lower byte until being read, like described above.
I really can’t imagine that Wiznet has screwed this up in the w5500 compared to the w5200. But I absolutely need to know for sure, so I think you are right again, and I have to wait for a statement from the Wiznet team.
If it really turns out to be impossible to read those registers reliably with one read access only, I think we will give up on the w5500 and look for another solution. While the “safe, but possibly incorrect” solution might eventually be acceptable for me personally, our customer probably won’t accept it, and he finally decides if we have to give up Wiznet after a decade or so due to this problem.
Thank you very much again!