Device does not send ACK after power-up

[PavelSv88]

Hello,
I have observed really weird behavior.

1. If I send first i2c frame ~20ms after power-up, device send ACK. Looks good.
2. If I send first i2c frame ~30ms after power-up, device does not send ACK.
   And the same if I use RST signal.
   If I start communication 15 - 25ms after reset signal, device communication is ok.
   If I start communication with 30ms delay after reset, device does not send ACK.

Have you observed something like this? I haven't found anything about this "timeout" in datasheet.

Thanks for you help.

[sgsharath123]

Hi @PavelSv88 ,
Please help us with more and specific details.

1. What cmd did you issue in first ~20ms frame when you get the ACK?
2. After ~30ms of power up, what frame (cmd) did you send?
3. Did you try again after ~30ms power up and down, to send the frame in ~20ms and check if you got ACK?

We need to understand the boundary conditions under which you're operating to pin point the issue.

[PavelSv88]

Hi @sgsharath123,
sure. My test procedure is very simple. I try to read I2C_STATUS register(0x82) from the device with address 0x30.

1. 20ms after power-up, i2c communication starts and very first frame (which is device address) is sent. In the case of 20ms start-up delay, ACK bit is low so the device acknowledged the frame and second frame is being sent. See below:
   
   Then, communication continues and I2C_STATUS is successfully read (Note: I read only very first byte of I2C_STATUS register which is 0x08)
2. If I repeat the procedure with delay 30ms after power-up, Very first i2c frame is not acknowledged as follow:
   
3. If start-up delay is 30ms, device does not send ACK, then if I do power cycle and change start-up delay to 20ms, device sends ACK.
4. I also tried this test with RST signal regardless on the power-up sequence.
   a) Set RST pin to LOW
   b) wait 100us
   c) Set RST pin to HIGH
   d) Wait Start-up time
   e) Read I2C_STATUS register from the device
   f) Wait 200ms
   g) Read I2C_STATUS register again
   ... repeat steps f) and g) in a loop

If Start-up time is 20ms - it works, device always sends ACK for every frame and reads register successfully.
If Start-up time is 30ms - it does not work, device never sends ACK.

Thanks for your help.

[sgsharath123]

Hi @PavelSv88 ,
What host device (i2c master) are you using to send the frames?
What do you mean by startup time here? What device is the point of reference for start up time, host or Optiga?

[PavelSv88]

Hi,

1. I use STM32H753 as a i2c master with using of ST HAL library(HAL_I2C_Master_Transmit/HAL_I2C_Master_Receive).
2. Start-up time is defined by datasheet as a delay between power-up(reset respectively) and first i2c frame. This start-up time is defined as at least 15ms. So, host waits ~20ms until it starts sending first i2c frame.
   

[PavelSv88]

And my problem is that if Start-up time (as shown on the picture above) is >25ms, device does not send ACK. Basically, it works only if Start-up time is between 15 and 25ms.

[PavelSv88]

Isn't it somehow related to the TRANS_TIMEOUT?
15ms Startup time + 10ms trans timeout would give my 25ms which Iam seeing.

[sgsharath123]

@PavelSv88 Can you try only connecting SDA SCL VCC (3.3V) and GND to Optiga from your STM host (if not already in this configuration) and check again?

[PavelSv88]

That was my first configuration. RST signal was originally connected to VCC via pull-up resistor. The behavior was the same. Then I tried to connect RST to STM host to be able to reset Optiga - but it did not help. So, I have already tried both configurations - with and without RST.

[sgsharath123]

In the case of communication that works ~20ms, does it still work when you send further i2c frames?
E.g. At ~20 (works), ~40 (?), ~60, ~ 90 etc.

[PavelSv88]

Yes, If I send first frame in 20ms after power up, and further frames 30, 50, 100ms after first one, all of them are acknowledged.
But if first frame is sent in 30ms after power up, it is not acknowledged and furtner frames are not acknowledged neither.

[sgsharath123]

Please check this issue thread and try the recommendations there and let us know if you still face the issue.

[sgsharath123]

OPTIGA™ Trust M goes to sleep mode in case no communication is detected after 20ms (default settings).
It wakes up automatically when its address is detected on the i2c bus, i.e. when a request is sent to OPTIGA™ Trust M.
It should respond to your request by waking up again.
You could try sending the i2c message until it responds as described in the note:

"The OPTIGA™ Trust M will not acknowledge the slave address sent by a host if it is either busy or in idle
state. Hence the host must retry or repeat the transaction until it is successful or timed out for 100
milliseconds (extreme case)."

Some hints here:
Poll until you get a response with a time-out of 100ms.

[PavelSv88]

That was what I was doing at the beginning - sending i2c frame in a loop with 100ms delay. But I never received ACK :( Anyway, development board should be on the way so I will try it on the dev board...

[sgsharath123]

Could you please try the following:

1. Send i2c request after >20ms from start-up
2. Send further i2c requests every 15-20ms
3. Repeat the above for 5-10 iterations (15-20ms * 5-10 = 75-200ms overall time-out)

[PavelSv88]

Sure, I will try it and send a screen of communication. Hopefully, it will work. It will be most likely on Monday as Iam out from Friday-Monday. Thanks a lot.

[PavelSv88]

Hi @sgsharath123,
I have tried the polling communication as you suggested - sending i2c request every ~16ms in a loop. But I never received ACK.

[sgsharath123]

Hi @PavelSv88 ,
We tried to reproduce your issue on our side and Optiga responds properly irrespective of the startup delay (of course any delay >15-20ms). At the moment, we feel the issue is with your HW setup or the Optiga unit you have.
Do you multiple Optiga devices to check that the above issue can be reproduced in other units?

[PavelSv88]

Hi, I should receive development board soon so I can try it on the board.
But I have some news regarding the polling communication:
When I tried to use polling mode with delay ~16ms between two frames, it did not work. I never received ACK.
If I use delay 10ms(or less) between two frames - it works.
If I use delay 12ms(or more) between two frames- it does not work.
Could you please explain what is the meaning TRANS_TIMEOUT register in the datasheet?
Thanks.

[sgsharath123]

TRANS_TIMEOUT (in ms) is the time duration in which the I2C transmitter considers that the frame it sent is yet to be ACK. After this time, the transmitter considers that the I2C frame it tried to transmit got lost. It is 10ms by default in Optiga Trust M.

[PavelSv88]

Do you think that Vcc rampup time could be a problem? Datasheet requires max 1ms. I have 2.5ms.

[pwiegele]

Hi @PavelSv88,

Did I understand correctly that you are currently porting the pal layer to your STM platform?
There is a pal layer implementation in here.
This is not for Trust M but the pal layer is quite similar.
Did you check the file here you can specify how the warm reset for the device shall be performed.
Did I understand correctly the device did not work properly with RST tied to VCC statically?

BR Paul

[PavelSv88]

Hi Paul,
Currently, my intention is to be able to read status register from Trust M to ensure I2C communication is fully working on my board. So, currently, I'm not porting entire pal layer to STM. I just use HAL STM layer to communicate via I2C.
At the beginning, RST pin was tied to VCC. I have implemented polling communication as follow: Send I2c frame, if ACK was not received, wait for 15ms and send the frame again. And repeat it until ACK is received. But I never received ACK.
Then, I changed waiting period from 15ms to 10ms and it works. I tried various waiting times (from 100us to 10ms) and it worked. But If I use waiting time >10ms, it does not work.
I will check pal layer implementation to see what is the timing there.

[SergiuBalmez]

Hi Pavel,
The default value for TRANS_TIMEOUT is 10 ms as per the Datasheet and is read only, the user can not change it.
For values > 10 ms, it will not work.

[PavelSv88]

Hi @SergiuBalmez,
does it mean that polling period must be < 10ms? That is not clear to me from the datasheet.

[SergiuBalmez]

Yes, by default 10 ms is the maximum timeout for re-transmitting the non-acknowledged frame. This is in the Spec, the same snippet you copied previously.

[PavelSv88]

Ohh, now I understand. Thank you very much. So, the polling period must be less than 10ms and more than 50us(guard time). I found that stack defines polling period to 1ms and 5ms by default. That makes sense. Thank you.