Can I2C High Speed mode be forced on without command bytes? (IMXRT1176)

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Can I2C High Speed mode be forced on without command bytes? (IMXRT1176)

跳至解决方案
1,871 次查看
bobbyjones0
Contributor II

I am using the IMXRT1176 as an I2C controller which I know is capable of running at the 3.4MHz High speed I2C clock. I have multiple I2C target devices on the same bus and I would like to bring everything up by default at 3.4MHz. Assuming I can do this on the target devices, my goal is to bypass the 400kHz negotiation phase and start the module directly in that mode. 

 I don't see any obvious way to configure this in the reference manual or examples. Is this possible?

0 项奖励
回复
1 解答
1,757 次查看
PabloAvalos
NXP TechSupport
NXP TechSupport

Hi @bobbyjones0 

 

Thanks a lot for being so patient waiting for my last answer.

 

After double-reviewing with my apps team, skipping the "controller code" that you mentioned before is an impossible task for changing from F/S to HS-mode on I2C, because it is highly needed to respect the protocol and the manual for it, as my apps teammate also followed, where it strongly stands that when you just initialize to use the protocol on your application, each connected device operates in Fast-mode. and then after certain time, you must send the ‘S 00001XXX A’ sequence'  and all the devices connected on the SDA bus have to recognize it, so then they have to switch their internal circuit from the Fast-mode setting to the Hs-mode setting, and unfortunately, there is no way to change that method, skip it or do it in another way.

 

So, with that said, and also answering your comment that "after every stop condition" you have to do it, it is totally correct, because when a STOP Condition occurs, "the active controller disables its current-source pull-up circuit" (that makes them to be HS-mode), to then, bring the bus system back into the F/S mode.

 

So please, do not hesitate to let me know your comments or more questions you have. Otherwise, please mark this answer as an accepted solution, I would really appreciate it.

 

Thank you so much.
Sincerely,
Pablo Avalos.

在原帖中查看解决方案

0 项奖励
回复
6 回复数
1,855 次查看
PabloAvalos
NXP TechSupport
NXP TechSupport

Hi @bobbyjones0 

 

Thanks a lot for reaching our technical support. I really appreciate your patience.

 

Regarding your question, I would like to know if you refer with this "bypass the 400kHz negotiation phase and start the module directly in that mode" to the fact that you want to initialize everytime your RT1176 with 3.4MHz on the I2C module, avoiding to configure it manually on the code that you want that frequency? It is unclear to me, because everytime that you create a new project and have I2C driver, you have to configure all the characteristics for your master I2C, and once you done, you upload all the code to your RT1176 and it will be always running when it is turn on or if you press reset button, the configuration code it will be always the same.

 

Hope you may clarify what is exactly what you are trying to do, please let me know if you have more questions or comments.

 

Thanks in advance.
Sincerely,
Pablo Avalos.

0 项奖励
回复
1,851 次查看
bobbyjones0
Contributor II

Hi Pablo,

I'm happy to clarify. What you're suggesting would be the case if I was looking to configure the bus at 400kHz. But to my knowledge that's as fast as you can set the I2C module during init. A transition to the 3.4MHz speed requires you to send a "S 00001XXX A" byte sequence on the bus which must be ACK'ed. According to the I2C spec this would have to be done during run time on every boot.

You can see a reference of what I'm referring to in section 5.3.2 of the I2C spec.

What I would like to know is if the IMXRT's I2C module hardware allows for a way to bypass this "controller code" byte sequence and just configure the bus to start at that SCL frequency on init.

0 项奖励
回复
1,790 次查看
PabloAvalos
NXP TechSupport
NXP TechSupport

Hi @bobbyjones0 

 

Thank you so much for all your patience.

 

Briefly, I will be back to you with a concrete answer after some questions and answers with my apps team. Please give me a little bit more time.

 

Hope you are well, please let me know some more questions or updates you have.

 

Sincerely,
Pablo Avalos.

0 项奖励
回复
1,780 次查看
bobbyjones0
Contributor II
No updates at this time. To provide some more context as to why I want to accomplish this: I've realized that you not only have to do this on boot, but also after every stop condition. I don't think I mentioned that in my earlier response. This significantly affects the overall transmission speed of single byte transactions.
0 项奖励
回复
1,758 次查看
PabloAvalos
NXP TechSupport
NXP TechSupport

Hi @bobbyjones0 

 

Thanks a lot for being so patient waiting for my last answer.

 

After double-reviewing with my apps team, skipping the "controller code" that you mentioned before is an impossible task for changing from F/S to HS-mode on I2C, because it is highly needed to respect the protocol and the manual for it, as my apps teammate also followed, where it strongly stands that when you just initialize to use the protocol on your application, each connected device operates in Fast-mode. and then after certain time, you must send the ‘S 00001XXX A’ sequence'  and all the devices connected on the SDA bus have to recognize it, so then they have to switch their internal circuit from the Fast-mode setting to the Hs-mode setting, and unfortunately, there is no way to change that method, skip it or do it in another way.

 

So, with that said, and also answering your comment that "after every stop condition" you have to do it, it is totally correct, because when a STOP Condition occurs, "the active controller disables its current-source pull-up circuit" (that makes them to be HS-mode), to then, bring the bus system back into the F/S mode.

 

So please, do not hesitate to let me know your comments or more questions you have. Otherwise, please mark this answer as an accepted solution, I would really appreciate it.

 

Thank you so much.
Sincerely,
Pablo Avalos.

0 项奖励
回复
1,815 次查看
PabloAvalos
NXP TechSupport
NXP TechSupport

Hi @bobbyjones0 

 

Thanks a lot for being so patient. I apology for the long delay and the issues that this might cause.

 

Regarding your question, I already asked to my teammates and I am waiting for an answer regarding your concern, so I will ask for you a little bit more time to reach you back with a concrete answer.

 

Thank you so much! I will stay tuned.

 

Best Regards.
Pablo Avalos.