- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
-
- Home
- :
- Product Forums
- :
- ColdFire/68K Microcontrollers and Processors
- :
- Problems with I2C on MCF5208
Problems with I2C on MCF5208
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Problems with I2C on MCF5208
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We are using MCF5208 processor and I2C is configured as Master. It has 4 I2C slave peripheral devices connected to it. Out of the four devices, two are on board and two are external devices which are connected through the buffers.
When one of the external peripheral holds the I2C bus by pulling the SCL line low, the bus busy status bit is set to 1 as expected. However, even after reinitializing the I2C controller, it is unable to communicate with any other remaining peripheral devices. Once this happens, the IIF bit in the I2SR is never becoming 1 for any read or write transactions, and the only option is to reboot the board.
For initialization we followed the steps given in the MCF5208RM.pdf document and couldn't find anything regarding I2C in errata. Is there anyway to reset the I2C controller alone in the 5208 other than the initialization sequence? Thanks in advance.
-Rambabu.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you check if the SCL line is being held low?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a design problem with the I2C bus. It can lock up if the master is reset during a transaction. When this happens the master is trying to start a cycle while the slaves assume they're in the middle of a cycle.
This may not be the cause of your problem, but by resetting the master you may be getting the system into this state.
I've known about this for years, and have found my I2C Reset code that says how you should reset the I2C bus prior to using it. You should send 9 clocks (to clear out any previous cycles) during I2C initialisation. In some cases you have to program the port pins as GPIOs and toggle SCL in software to do this.
Google "i2c bus lock up reset " finds:
I have had a only a bare handful of projects where under certain circumstances an I2C slave may "lockup" (generally by not releasing SCL if a lockup happens during clock stretching -- masters that do not timeout under these circumstances usually fall into their own endless loop as well because SCL never goes high). There are workarounds of course: polling SCL, bit-banging I2C routines to ensure that I2C transactions timeout while waiting for a slave to release a line, power cycling the slave, etc.
However, I came across this tidbit in a datasheet from Atmel (an I2C 32kbit SOIC EEPROM)
doc said...
After an interruption in protocol, power loss or system reset, any 2-
wire part can be reset by following these steps:
(a) Clock up to 9 cycles, (b) look for SDA high in each cycle while SCL is high and then
(c) create a start condition as SDA is high.
The following are usually similar.
http://www.microchip.com/forums/m45683.aspx
http://www.utasker.com/forum/index.php?topic=990.0;wap2
http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/49472.aspx
Tom
