X-NUCLEO-NFC01A1 I2C Timeout problem

[MFo.1]

Hello, i have a strange problem with x-nucelo-nfc01a1 shield.

I get an i2c timeout but under different conditions it occurs in different places in code.

My setup is nucelo board with stm32L073RZ and X-NUCLEO-NFC01A1 shield, and to communicate with M24SR module i am using xcube libraries, which i downloaded from st.com site.

Case 1.

I2C is configured to 100kHz.

I2C timeout occurs during initialization phase. From my observations it looks like the transmission holds during sending verify command (M24SR_Verify()).

The I2C_WaitOnTXISFlagUntilTimeout() function in HAL_I2C_Master_Transmit() returns I2C_TIMEOUT and it is always in the half of transmission.

The verify command is 24 bytes length, and when timeout occurs hi2c.Instance.XferCount is equal to 12.

So in result i cannot even initialize the module.

Case 2.

I2C is configured to 400kHz or 1000kHz.

Initialization phase passes with success. I can even write and read an URL using TT4_WriteURI() / TT4_ReadURI().

But when i try to write for example vcard or sms, i2c timeout occurs again.

I have no idea whan can cause this. From smartphone i can write and read any type of record.

PS. I've one additional question.

Shouldn't be in lib_NDEF.c in function NDEF_ParseSP() in line 328

if( NDEF_IdentifySPRecord ( pSPRecordStruct, pPayload ) == SUCCESS)

instead of

if( NDEF_IdentifySPRecord ( pSPRecordStruct, pPayload ))

as the SUCCESS code is 0?

Thanks,

mf

[Rene Lenerve]

Hi @MFo.1​ ,

There is a defined constant M24SR_I2C_TIMEOUT (in the file drv_I2C_M24SR.h), this constant is set at 200 (in ms if the Tickcount is configured to 1ms). This 200 ms should cover all command sent to the M24SR. So you can check if your tickcount is correctly set to 1ms, if it is not the case you could increase it to give enough time for each command to be completed.

To answer your additional question, both lines are correct until someone decides to change default value of SUCCESS, this will make the second one false. So for a question of code maintenance the first is preferable and it is often part of coding rules.

Hope this can help you

Best Regards.

[MFo.1]

Hi Rene,

thanks for answer.

About the second part of your answer, i think you did not understood me correctly.

This code which i posted above is from library developed by ST for X-NUCLEO-01A1.

SUCCESS is defined as

typedef enum 
{
 SUCCESS = 0,
 ERROR = !SUCCESS
} ErrorStatus;

in stm32l0xx.h and

if( NDEF_IdentifySPRecord ( pSPRecordStruct, pPayload ))

is original line from lib_NDEF.c line 328. So if SUCCES = 0, this condition wouldn't pass if NDEF_IdentifySPRecord return SUCCESS.

After i changed this line to

if( NDEF_IdentifySPRecord ( pSPRecordStruct, pPayload ) == SUCCESS)

it works well. So i think this is a little bug in this library.

Second thing. Currently i am testing X-NUCLEO-02A1, also with library developed by ST (downloaded here ).

And i think i also found a bug in this library.

In file lib_NDEF.c at line 450 we can find

pRecordStruct->PayloadBufferAdd = pNDEF;

and i think the pNDEF buffer should be shifted by records header size like:

pRecordStruct->PayloadBufferAdd = pNDEF + SizeOfRecordHeader;

to be able to correctly parse record header with function

NDEF_ParseRecordHeader( pRecordStruct );

I'm wondering if these libs are stable versions as they aren't available from CubeMX (only from STs site). Only package for X-NUCLEO-04A1 is available from CubeMX.

Did you used any of these libraries?

Regards,

mf

[Rene Lenerve]

Hi @MFo.1​ ,

Yes you are right, I was misunderstanding your question.

These errors have been fixed in an updated library but not in those packages. The latest stable version could be found in the NFC4 package that you can found on st.com. But this latest version bring lots of modifications and you will have some adaptation to do for integration.

Hope this can help you.

Thank you for reporting these issues.

Best Regards.