Hi Kevin,
Are you free sometime today for a call to talk about this project?
Tim,
I had not seen that the clock was idle high and I had my driver set to low. I switched it to high and verified that I do not have an idle time of longer than 5 us during transmission (longest is about 1 us) and that I have a minimum idle of 10 us between whole transfers. See attached capture from our logic analyzer of the first transmission after changing to idle high. Now no CRC is even sent from the module
Hi Kevin,
Could you please include the timescale on the picture that you just posted? Also just wanted to see if you saw the previous message to see if you’re available for a call today
It also looks like you need to have your CPHA and CPOL set to be 1. It seems like your sample point is 180 degrees out of phase
Tim, I’ve attached a new image. The software doesn’t support an export longer than the display window the so the relative time scale appears incorrect but the major tick marks are placed every 5 us. And yes I am available to call any time, would you like me to call this number: 312-893-5636
I’m just going to get my colleague and we’ll give you a call in a couple of minutes
Hi Kevin,
After the phone call I was talking with Jon on some potential workarounds for this and we were thinking it could potentially be possible to do this by making a hardware modification that would invert the clock cycle. As long as there isn’t too large of a propagation delay and the frequency of the clock doesn’t cause any issues, this might be something worth looking into
Tim,
I have been able to confirm in the low level code of my driver that I actually am running with CPOL and CPHA both set to 1. I think the problem is that with my first frame, the clock line is still starting low and only idles high AFTER the first frame. I’m assuming that the > 10 us idle high time between frames needs to come at the beginning of the first frame as well. Can you confirm that? I’m looking into this further but want to make sure that’s needed before I sink too much time into it
The issue has been resolved! After finding that I could set my driver CPHA and CPOL both to 1 but seeing that the clock was still idle low until the first message came through, I had been trying to get the clock pin to start high before the first message went out. This was not working so I finally let the program go with no breakpoints and collected the first handful of messages and realized that after the first one fails, it’s retransmitted as expected and then the ball gets rolling for the remaining initialization. Thank you for your help. I would suggest that the hardware implementation guide actually called out CPHA and CPOL instead of just showing it in the diagram because I overlooked it entirely (partially due to the bad luck of getting a successful exchange while in the wrong mode
Hi Kevin,
Glad to see we got it working, I’ll see if we can get the people who make the documentation to put a note in about the CPHA and CPOL
Topic closed due to inactivity.