how to reset I2C peripheral on Kinetis K20?

cancel
Showing results for 
Search instead for 
Did you mean: 

how to reset I2C peripheral on Kinetis K20?

2,009 Views
bowerymarc
Contributor V

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.

Labels (1)
Tags (1)
22 Replies

282 Views
abidbodal
Contributor II

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 

0 Kudos

282 Views
BlackNight
NXP Employee
NXP Employee

:-)

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

0 Kudos

283 Views
egoodii
Senior Contributor III

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.

0 Kudos

283 Views
bowerymarc
Contributor V

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. 

0 Kudos

283 Views
egoodii
Senior Contributor III

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.

0 Kudos

283 Views
bowerymarc
Contributor V

No-trolling.jpg

0 Kudos

283 Views
egoodii
Senior Contributor III

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...

0 Kudos

283 Views
bowerymarc
Contributor V

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

0 Kudos

283 Views
egoodii
Senior Contributor III

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.

283 Views
bowerymarc
Contributor V

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.

0 Kudos

283 Views
egoodii
Senior Contributor III

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.

0 Kudos

283 Views
bowerymarc
Contributor V

'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.


0 Kudos

283 Views
egoodii
Senior Contributor III

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

0 Kudos

283 Views
bowerymarc
Contributor V

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

0 Kudos

283 Views
egoodii
Senior Contributor III

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.

0 Kudos

283 Views
bowerymarc
Contributor V

did you actually test this?

0 Kudos

283 Views
egoodii
Senior Contributor III

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

0 Kudos

283 Views
bowerymarc
Contributor V

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

0 Kudos

283 Views
OliverSedlacek
Contributor III

@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

0 Kudos

283 Views
bowerymarc
Contributor V

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.

0 Kudos