Incorrect reading Sn_SR againe
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: Incorrect reading Sn_SR againe
by Candela12 ·
Yes, the 0x1,0x2,0x3 bit is true, this can be seen in my analyser pics in the lost interrupt thread too.
RE: Incorrect reading Sn_SR againe
by zer0 ·
Hello,
I’m currently working on a project using a STM32f4 and a module based on W5500 (the most common one on amazon, with a yellow connector).
Sorry to bump this old topic, but it seems that I’m experimenting the exact same issue than alenic: reading or writing to some specific address fail. This occurs for instance for the socket status register (addr = 0x3 in socket block), but also with GAR1 (addr = 0x2 in common block).
I can read the value of GAR0 (100% success with 100000 tries), but I fail to read GAR1 (99.8% failure with 100000 tries). My SPI receive function checks for the 0x1, 0x2, 0x3, and fails if one of the received byte is wrong.
This is what I receive when it works (GAR0):
tx 0x00 0x01 0x00 0x00rx 0x01 0x02 0x03 0xc0This is what I receive when it works (GAR1):
tx 0x00 0x02 0x00 0x00rx 0x01 0x00 0x06 0x01(2nd, 3rd and 4th rx bytes are wrong)
So, it seems the failure occurs before the control phase (3rd tx byte) is received, so it does not depend on register block, read/write access, or SPI operation mode.
It looks that SPI phase and polarity is correct, but I tried the 4 combination to be sure. I also decreased the speed by a factor 8 (I’m below 1 Mhz). Unfortunatly, I have no logic analyzer to capture the signals, which would probably help.
Like [alenic], I can workaround the problem when accessing to the socket status register by doing an access to 3 bytes starting at the socket control register, but this won’t help when I’ll be accessing Tx/Rx buffers.
Any idea would be really welcome !
Thanks
RE: Incorrect reading Sn_SR againe
by alenic ·
Hello, try to reduce clk, miso, mosi lines. It’s help me to solve the problem.
RE: RE: Incorrect reading Sn_SR againe
by zer0 ·
Hi Alenic,
Thank you for your answer. You mean the length of the cable, not the frequency, right ? Currently I’m using 20cm “dupont” cables for prototyping. Do you think there can be bounces on the lines?.. especially knowing I decreased the SPI frequency to 200Khz!
(EDIT: I did a test by changing GPIO speeds in STM configuration, I had the impression that it changed something, but after several tests, it is not reproducible at all…)
I’ll try to change the cables, but I don’t have a lot of hardware, so it won’t be that easy
Anyway thanks again, and if anyone has another idea, I’m still interested!
RE: Incorrect reading Sn_SR againe
by alenic ·
Yes, I mean length. May be the problem was in contact quality, I am not sure. I have some cables with different length. I just replaced the cables to shorter and it solved my problem.