cancel
Showing results for 
Search instead for 
Did you mean: 

X-NUCLEO-NFC08A1 - IO configuration register 1 always reads 0xFF

Mark-EQ
Associate II

I am using a NUCLEO-L053R8 board with an X-NUCLEO-NFC08A1 extension. I made modifications to the NFC08A1 to enable I2C communications and this works. I can read the A bank of registers and the values all make sense except for IO configuration register 1. It should have all 0s for the default value, but it always reads 0xFF. I can read, write, and read back IO configuration register 2 just fine. Even if I try to write all 0s to IO configuration register 1, it always reads back as 0xFF. I set up a scope to capture the i2c activity and it agrees with the firmware.

 

Our firmware is custom, and we can successfully operate an NFC07A1 board.

 

I am attaching a picture of the scope screen.

This discussion is locked. Please start a new topic to ask your question.
1 ACCEPTED SOLUTION

Accepted Solutions
Mark-EQ
Associate II

I found that HAL_I2C_Mem_Read will do the i2c operation without the stop conditions. I still had the problem, but I found by setting the 0x40 bit in the register address passed to that function, to make the mode byte correct, it works correctly. I no longer get the mysterious 0xFF result.

View solution in original post

3 REPLIES 3
Ulysses HERNIOSUS
ST Employee

Hi,

if I read this scope shot correctly (green brace: I2C START and red brace: I2C STOP) then the read is performed following as two separate I2C transactions. Reading needs to be performed by a repeated START condition.

BR, Ulysses

Mark-EQ
Associate II

The phone picture I attached does not show the color well, but the bracket before the second 50 is green, showing the start condition.

We found something in the documentation that could partially explain this, in st25r3916b, Figure 29. It says "If the I2C controller omits the mode byte and reads the ST25R39xxB immediately after the target address, then, as shown in Figure 29, it will first output the byte FFh, followed by a register dump starting at address 01h."

This is exactly what we are seeing, but it is my understanding that the 40 is the mode byte. It seems like that is not being recognized. 

Mark-EQ
Associate II

I found that HAL_I2C_Mem_Read will do the i2c operation without the stop conditions. I still had the problem, but I found by setting the 0x40 bit in the register address passed to that function, to make the mode byte correct, it works correctly. I no longer get the mysterious 0xFF result.