IGNACK behavior on S32K14x

[Joey_van_Hummel]

My previous post on this got marked as spam and deleted (why?) so I'll try again.

Hi all,

When LPI2C master IGNACK is set, I am still seeing NDF set on NACKs and new start condition is not possible. 

I need to clear NDF to start new frames, even though IGNACK is set to 1.

Is this expected behavior?

Kind regards,

Joey

[Senlent]

Hi@Joey_van_Hummel

Sorry to keep you waiting. I don't know why your previous post was marked as spam. It was not marked manually, but automatically by the system.

Regarding your question, I think the following situation may cause your situation.

First, let's look at the description of the NDF register:

From this sentence, we can know that if we set it at the beginning to expect to receive NACK, but we did not receive NACK, then the NDF bit will also be set.

For example, if we set CMD to expect to receive NACK, but we actually received ACK, then NDF will be set. At this time, you need to manually clear the NDF bit to start a new transmission.

The above is my understanding, you can check the CMD settings, this may be the cause of the problem.

[Joey_van_Hummel]

Hi @Senlent,

Thanks for your reply, I appreciate your time. I am referring to bit IGNACK in register MCFGR1.

See the following description:

It was my assumption that the receiver mechanism would not flag NDF and would not prevent start/stop under any circumstances if IGNACK is set. 

This is also written further in Functional Description, under section 52.3.2.5 Error Conditions which states:

The LPI2C master will monitor for errors while it is active, the following conditions will generate an error flag and block a new START condition from being sent, until the flag is cleared by software:

- NACK is detected when transmitting data, and MCFGR1[IGNACK] is clear (sets MSR[NDF]).

- NACK is detected and is expecting ACK for the address byte, and MCFGR1[IGNACK] is clear (sets MSR[NDF]).

- ACK is detected and is expecting NACK for the address byte, and MCFGR1[IGNACK] is clear (sets MSR[NDF]).

My conclusion is that IGNACK does not work as the RM describes, hence my wondering if this is expected behaviour or perhaps an erratum.

I am using normal Transmit Address and Data commands (100b and 000b).

Kinds regards,

Joey

[Senlent · Accepted solution]

Hi@Joey_van_Hummel

Thanks for reminding me, I actually saw IGNACK this errata.

So, your guess is right,

https://www.nxp.com/products/S32K1

[Joey_van_Hummel]

Hi @Senlent,

Thank you for confirming. I had found an old version of the erratum document which doesn't list this erratum.

I see that there are new versions which do list the problem.

Thank you for clearing this up and showing me the new erratum data. I've implemented the proposed workaround and that works.

Thanks again for your time,

Kind regards,

Joey

[Senlent]

Hi@Joey_van_Hummel

You're welcome,