TC3XX: I2C Register Lock Issue

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
User22574
Level 1
Level 1
First solution authored
Hello!

We are currently designing a project with TC399XE. And we found a problem while trying to set up an I2C communication (on chip, between two modules).

Problem is that there is a register called RUN Control Register (RUNCTRL), which has only one bit field writable (RUN). It is used to enable/disable I2C interface bus. If some configurations of current operation is needed, RUN needs to be disabled (RUN = 0), then user can set up various configuration settings to I2C module, then RUN is enabled (RUN=1). Consequence of latter instruction is that all configuration registers are locked (cannot be accessed to either read/write operations). So far everything is fine and expected, but what conflicts with information from reference manual is that after RUN=1, besides configuration registers (ADDRCFG, FDIVCFG, TIMCFG) also control registers (RUNCTRL, ENDCTRL, TPSCTRL,...) are being locked. This is not desired as, for example TPS bit fields of TPSCTRL register needs to be written to start transmission from master but now this cannot be done since TPSCTRL is not accessible as I2C bus is enabled.

During I2C set-up we also followed FSM diagram which clearly indicates needed operations to be executed for desired operation. As another example, referring to Figure 327. Master Process Sub-state Machine from TC3XX reference manual (v. 2.4.0.), it shows that from LISTENING state (RUN = 1), master must set TPS (or size of packet to be transmitted) which starts transfer of bytes to slave - TSP must be set in software (M1 process). Later, after bytes are transmitted, master must set END (from ENDDCTRL register) to put stop condition on the bus to stop transfer and return to LISTENING STATE (M16 process). But during both manual (in software) writes to TSP and END bit fields, RUN = 1, meaning all both bit fields are not accessible (although they should be).

All other I2C related registers remain unlocked (can be read from written to) after RUN is enabled, meaning RUN (from RUNCTRL register) is responsible for locking configuration as well as control registers and not any other register, responsible for locking certain registers (for protection).

We checked Errata (up to v.11) and found no solution to described problem.

Here is also initialization code and basic data transmission call function.
0 Likes
1 Solution
User22574
Level 1
Level 1
First solution authored
@MoD
Problem has already been solved with help of Infineon iLLD (Infineon Low Level Driver) libraries. I wasn't considering RMC bit field of CLC1 register (clock divider option - was set to 0 by default, meaning CLC1 module was disabled)

View solution in original post

0 Likes
7 Replies
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
I don't know where you find the information that RUN=1 locked also the control registers. Also in the old TS V2.4.0 I can't find this.
As described only the configuration registers are locked when RUN=1.
Your problem is that you don't enable the clock correctly. Register I2C0_CLC is endinit protected, this means first you must clear the endinit bit of CPU0WDT then write the I2C0_CLC register then set the endinit bit of CPU0WDT.
0 Likes
User22574
Level 1
Level 1
First solution authored
@MoD

Thank you for that information. However, when writing to CPU0WDT ENDINIT bit field program crashes, as it cannot write to that register, meaning that register is also locked?
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
Yes, to write to this register you must use specific sequences. Please see the iLLD or compiler files, there are included functions to change the endinit bit.
0 Likes
User22574
Level 1
Level 1
First solution authored
@MoD I configured protection registers the right way so that CLC register can be written to. But problem still remains - when RUN = 1 (from RUNCTRL), configuration and control registers are not accessible, while all other I2C registers remain normally accessible. But all this happens right after RUN = 1.

Is there any possibility for you to verify this issue on TC3xx family?

Otherwise, we have multiple boards with TC399XE and we tried setting up I2C on all of them and get same results (meaning I2C module on current board isn't broken/damaged).
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
Such a behavior we never seen. The problem is your software.
I had another look in your code snippet. Independent of the described behavior you can't use the module by the way you expect. You can download the iLLDs from here: Software Documentation
There you can find a working driver and also a demo for the master mode. This should help you to understand what you must do at which time. Also the demo software of the TriBoard use the iLLDs to access the I2C eeprom on board.
0 Likes
User22574
Level 1
Level 1
First solution authored
@MoD I'm sorry, but I cannot access that link you kindly provided (cannot log in with user account). Otherwise I would be very interested of seeing some already operational software sample for TC3xx I2C module.
0 Likes
User22574
Level 1
Level 1
First solution authored
@MoD
Problem has already been solved with help of Infineon iLLD (Infineon Low Level Driver) libraries. I wasn't considering RMC bit field of CLC1 register (clock divider option - was set to 0 by default, meaning CLC1 module was disabled)
0 Likes