5.116 I2C issues

[Ttelmah]

My thought is that when he switches between the modes, the lines are
in different states for the I2C and the SPI. This generates a spurious
clock on the SPI, resulting in the shift register having one bit already in
it. Doing the second init (because this turns the peripheral off then on
again), clears this spurious clock. In both cases, though the clock is an
output, you can artificially clock it when the PPS is switched.

[newguy]

So the presence of the spurious clock messes with the MSSP internally somehow?

With one SPI initialization, what would happen is that there would be no *external* activity on the SPI lines at all. The processor would hang somewhere in the code that addressed the accelerometer. Two initializations allow there to actually be SPI traffic on the SPI lines and the code doesn't hang as a result.

I have to again state that the SPI and I2C lines are physically different. There is no sharing or dual usage of any line between the I2C and SPI ICs on the PCB. I acknowledge that PPS changes might induce some internal weirdness inside the MSSP but not sure why that should screw it up if the PPS changes occur while the MSSP is disabled?

At any rate, I've opened a Microchip support ticket. I'll report back with any updates as I receive them.

[Ttelmah]

Yes.
I've seen some other PIC problems, where a register 'thinks' it is getting
data or clocks from a different source, and stops retrieving the ones
it should get. A couple of these are now in the errata for their chips
after MicroChip managed to repeat this. Are you pin selecting before or
after the spi_init?.

[Ttelmah]

Thinking about it, I'd try selecting to NONE, before selecting to the
new pin.

[newguy]

The general flow is:
- disable MSSP.
- set 'in use' MSSP pins (be that SPI or I2C) to 'none', then configure the 'on deck' pins to either SPI or I2C.
- enable MSSP in the proper mode.

In going from I2C to SPI, the SPI pins are already set to 'NONE' in terms of PPS. Even if there is electrical noise that arises from the PPS actions, there's still a few clock cycles between setting them and then ultimately enabling the MSSP.

And as of a few minutes ago, Microchip has now 'escalated' the ticket.

[newguy]

Microchip's quick & dirty suggested fix is to use PMD to remove power from the MSSP, then reapply power (again via PMD) before doing a single initialization of the MSSP. It's only been a few minutes, but it's working so far. Given that it would lock up in seconds at most before, it looks to be a potentially valid solution.

Will leave this running overnight and report back in the morning.

[Ttelmah]

That makes very good sense.
As you say, 'dirty', but it does mean you are starting into each state
from a power off condition.
This will undoubtedly now be in the next erratum for the chip. Will
be interesting if they find a neater solution to this.

[newguy]

Yes it makes complete sense and I'm a little disappointed in myself for not thinking of it first.

They were very specific that I should toggle the power to the MSSP and then restore it back-to-back. I remember from the last time I dealt with a very low power project (the LoRA device I mentioned earlier) that I read somewhere in the data sheet/errata for that (different) processor that they recommended at least one nop() after enabling a peripheral before you should attempt to interface with it. For this current project I threw in a delay of 2 cycles after removing power and another 2 cycle delay after restoring it before I start to initialize the MSSP in SPI mode.

I'm happy to report that it's been about 10h since I implemented this workaround and it's still happily running properly.