CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

5.116 I2C issues
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 19463

View user's profile Send private message

PostPosted: Tue Oct 17, 2023 9:18 am     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1907

View user's profile Send private message

PostPosted: Tue Oct 17, 2023 9:40 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19463

View user's profile Send private message

PostPosted: Tue Oct 17, 2023 11:00 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19463

View user's profile Send private message

PostPosted: Tue Oct 17, 2023 11:33 am     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1907

View user's profile Send private message

PostPosted: Tue Oct 17, 2023 12:03 pm     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1907

View user's profile Send private message

PostPosted: Tue Oct 17, 2023 9:50 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19463

View user's profile Send private message

PostPosted: Wed Oct 18, 2023 3:38 am     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1907

View user's profile Send private message

PostPosted: Wed Oct 18, 2023 7:58 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group