Hm2 bspi fixes #2288
Hm2 bspi fixes #2288
Conversation
The BSPI module has a receive fifo and a transmit fifo per instance (shared among all the channels of that instance). Writing anything to the fifo count register clears both fifos, discarding any old read data and any pending write data.
Writing to BSPI channels with echo enabled also simultaneously reads from those channels. The read bytes go into the BSPI instance's read fifo, where they stay until the driver reads them out. By writing to the (echo-y) ADCs to configure them, we also put some bytes into the read fifo. When we later try to read the analog and digital inputs, we'll actually get the old bytes from the ADC setup, and everything will be off by a handful of bytes, resulting in incorrect information being used. This commit fixes the problem by clearing the FIFO after setting up the ADCs. There may be another bug lurking in here - if somehow the FIFO becomes out of sync, we'll never recover. A future hacker will get the pleasure of rediscovering this problem and fixing it.
|
What prompted this? I wasn't aware of an issue. |
|
Sorry, this change was a bit rushed, and as it turns out it may have been in error... @jepler and @cradek and I are building a new machine, using a 7i80 and a 7i65. It's probably also worth mentioning that we're using a custom 7i80 firmware from @pcw-mesa. We were observing bogus results when reading the SPI peripherals on the 7i65:
We (well, Jeff, who's the brains of our group) observed the following things:
From this we we formed the theory that there was unexpected stuff in the BSPI receive FIFO, before the values the driver expects based on the TRAM packet. Those junk frames in the receive FIFO would get read out before the actual frames that the driver expects. The old junk frames in the FIFO would still get interpreted according to the TRAM structure, and parsed into analog and digital hal pins, leading to the corruption we were seeing. We inserted the "write anything to the BSPI FIFO Counter register in order to clear the FIFO" change, and it appeared to fix the problem. So we merged to 2.8 and merged up to 2.9, where we needed it. But then we rebooted and the problem came back, so we must be mistaken about something here... We'd love extra eyeballs on this. Are the 7i65 BSPI inputs (ADC and CPLD digital inputs) working right for you @andypugh? Were they working before our change, for example on 2.8.4? |
|
I do have a 7i65, but I am busy each evening until the weekend, then off to the Alps to slide down them. So I don't know when I will be able to get to it. This thread might warrant further study: https://sourceforge.net/p/emc/mailman/message/29739585/ |
|
What's the status on these changes to bspi? I'm having some trouble getting any life out of bspi using a 7i92 with a stripped down 7i65 component. Not sure these issues are the same as mine but it doesn't look like they are specific to the 7i65. |
|
One improvement I can see is is for the read function to check if the expected amount of data is in the RX FIFO |
This PR makes the Mesa 7i65 board inputs work right for us.