how to reset I2C peripheral on Kinetis K20?

[bowerymarc]

The I2C peripheral is getting wedged sometimes and it seems there's no way to completely reset the peripheral - is there?

Nothing apparent from combing the manuals.

[abidbodal]

Thanks for the info. Erich Steyger's post was great. Here's a whitepaper that describes the issue really well:

http://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf 

[BlackNight]

:-)

For the record: the post his here: https://mcuoneclipse.com/2013/12/08/bit-banging-i2c-with-resetbus-functionality/ 

And that ResetBus() functionality has rescued my devices many times.

Erich

[egoodii]

The 'general case' for any I2C peripheral that may get 'lost' decoding the I2C protocol is to be 'reset' by a sequence of 9 clocks (data undriven) and a 'stop'.  This, of course, assumes the 'master' has CONTROL of the clock!  If this isn't true (due to slave clock-stretching gone awry, or you've 'muxed in' an I2C segment dragged 'low'), or this isn't the kind of 'reset' you need, then you will have to find some 'extra' capability in your peripheral that allows for a reset (if it has one!).  You may have to take direct control of the I2C pins in the 'master' to accomplish this I2C sequence in 'bitbang' mode.

[bowerymarc]

I'm talking about the i2c peripheral internal to the Kinetis processor.  I want to reset it internally using the processor core somehow if possible. 

[egoodii]

Disabling the module clock for a bit might reset an I2C module, I don't know -- but excepting for 'known errata' on-chip-modules don't 'get lost', you clearly have firmware faults if you are losing control.

[bowerymarc]

[egoodii]

I don't know what that means, but all I am saying is that if your firmware is letting the I2C module get 'wedged' somehow, then I think you will be 'much happier' having a reliable result by finding that cause, rather than 'hoping' a module reset will get you out of trouble...

[bowerymarc]

Unless you actually know the answer please keep this area clear for an answer to the original question.  Keep it professional. Thanks.

[egoodii]

You asked a one-line question, I am trying to give the best information I can.  The simple answer, to what you asked, is "it can't be done" -- which leads to the next concepts of trying to help understand WHY you would like to have such a function, and what we might supply to help that along.  I don't get paid to cruise this forum...

You might start by giving a more complete description of what 'wedged' means.

[bowerymarc]

Your first answer to the question ("I don't know") is more credible than your second.

The I2C peripheral has within it a state machine, which is reset with the chip reset. IICEN seems not to reset the state machine. Like any state machine, you can get to the 'idle' state directly through a reset, or by walking it through states to get to idle.  Anyone with a basic education knows the details and complications of that statement.  So, perhaps there's a fool-proof way of walking the I2C peripheral to Idle, or another bit or bits in a control register that might do the job.  Not evident, as I said, from the doc.

Let's leave the thread clear for someone who might actually authoritatively know the answer.  Hopefully, an engineer from Freescale.

[egoodii]

I'm afraid you will find that the steps necessary to 'walk' the state-machine back to idle depend entirely on the state the module is 'in' at the time, leading back to needing to know 'in what way' the I2C module is failing for you, so that ANYONE in this forum would have enough information to supply a complete answer.

[bowerymarc]

'Fool-proof' would mean from any state, and the question really is whether that's even possible... not enough public doc to determine.

Please keep the thread clear for someone with some useful knowledge to impart.  Keep it professional.  Thanks.

[egoodii]

That's still a very un-specific question.  Let's just start with 'master' or 'slave' mode?

[bowerymarc]

You already said you didn't know, so just leave it at that.

[egoodii]

In other words, from 'master' mode the clear of the 'master' bit, and other flags, is the 'state return to idle' you ask for, but as part of a 'system' you must also clear the bus and slaves, and internal to the Kinetis any 'connected' modules of interrupt and/or DMA.

[bowerymarc]

did you actually test this?

[egoodii]

I have never come across any 'unspecified faults' to test it, but it's in there...

[bowerymarc]

so basically you have offered up:

1. an answer to a question I did not ask and do not need (recovering the I2C bus), for the third time.

2. an untested (and by the way, logically flawed) theory on how to recover the I2C peripheral.

....which appears to be the entirety of your knowledge on the subject so hopefully that'll be your final post here.  So now I'm looking  forward to hear from someone else, anyone else, who (a) has run into this situation and has a tested solution and/or (b) freescale engineer with access to internal doc that would provide a useful answer.

regards

[OliverSedlacek]

@Marc, I seem to be in the same boat as you with my K60 I2C peripheral getting wedged. I take it you haven't found a solution yet?

Oliver

[bowerymarc]

What I ended up doing is using a bitbanged I2C driver.  I modified Erich Steyger's GenericI2C PE component, fixed the timing, added support for FreeRTOS so it wouldn't choke the CPU while doing transfers, and wrote a very robust (if I do say so myself!) reset routine, based on a bunch of different approaches out there (each of which had good insights but missed something another one had...)

I could do that because I didn't need any type of fast transfer speed.  It's been working well, and Erich pushed all my changes back into his driver, so if you d/l the current version you'll get all that stuff.

in a nutshell, I had multiple problems: the SigmaDSP had a faulty power supply setup which made it flaky, and the I2C_LDD driver design pattern is basically inappropriate for transferring huge swaths of data like a chunk of program code, due to the amount of RAM you have to allocate to do it.   If you're using the I2C peripheral, better to use the Init_I2C PE component, and then import the I2C_PDD macros and use those, and customize the DMA to your own purpose, or possibly end up not using it.