2018-09-18 03:23 AM
Hello everybody,
I am having an issue when I try to establish a communication with the NFC chip M24SR64 via I2C. After I have sent the address (0xAC), the flag AF is set, indicating that the ACK of the slave was not read. However, I can see the ACK from the slave in the Oscilloscope, i.e., during the 9th SCL pulse the SDA line is in low (see attached picture). Then, in the error handler subroutine for the AF case, a STOP condition is generated. I repeat the process many times but always the AF flag is set.
I am pretty sure my I2C settings are right (PF0 and PF1 as open drain outputs, high speed, alternative function, etc). In fact, the I2C driver works flawlessly in the STM32F446. I compared the two reference manuals and there is no difference in the I2C modules of the controllers.
The pull-up resistors value remained the same (3K) . I also attached my initialization code.
Thanks for your help.
// Set I2C eState Busy
NFCL_tIICHandle.eState = I2C_STATE_BUSY;
// Disable the selected I2C peripheral
I2C_NFC->CR1 &= ~I2C_CR1_PE; // 0: PE: = 0: Peripheral disable
I2C_NFC->CR1 |= I2C_CR1_SWRST;
I2C_NFC->CR1 &= ~I2C_CR1_SWRST;
// Get PCLK1 frequency
u32Presc = ((RCC->CFGR & RCC_CFGR_PPRE1)>> POSITION_VAL(RCC_CFGR_PPRE1));
u32Pclk1 = (UINT32)(RCC_SYS_CLK >> i2c_au8APBAHBPrescTable[u32Presc]); // PRQA S 3393 //RCC_SYS_CLK causes the warning!
// Calculate frequency range
u32FreqRange = I2C_FREQRANGE(u32Pclk1);
// Configure I2C2: Frequency range
I2C_NFC->CR2 = u32FreqRange; // PCLK1 = 50 MHz
// Configure I2C2: Rise Time
I2C_NFC->TRISE = I2C_TIME_RISE; // TRISE = 0x10
// Configure I2C2: Speed I2C clock control
I2C_NFC->CCR = 0x2A // 0-11: CCR = 0x2A (42): Clock Control Register (2500ns / (3 * 20ns) = 42)
// 14: DUTY = 0: Fast Mode Duty Cycle
| I2C_CCR_FS; // 15: FS = 1: Master mode selection
// Configure I2C2: Generalcall and NoStretch mode
I2C_NFC->CR1 = I2C_GENERALCALL_DISABLE // 0: PE: = 0: General call disabled. Address 00h is NACKed.
// 1: SMBUS: = 0: I2C mode
// 2: Reserved, must be kept at reset value
// 3: SMBTYPE: = 0:
// 4: ENARP: = 0: ARP disable
// 5: ENPEC: = 0: PEC calculation disabled
// 6: ENGC: = 0: General call disabled. Address 00h is NACKed.
| I2C_NOSTRETCH_DISABLE // 7: NOSTRETCH: = 0: Clock stretching enabled
// 8: START: = 0: In Master Mode: 0: No Start generation
// 9: STOP: = 0: In Master Mode: 0: No Stop generation.
| 0; // 10: ACK: = 0: No acknowledge returned
// 11: POS: = 0: ACK bit controls the (N)ACK of the current byte being received in the shift register.
// 12: PEC: = 0: No PEC transfer
// 13: ALERT: = 0: SMBus alert, Releases SMBA pin high
// 14: Reserved, must be kept at reset value
// 15: SWRST: = 0: I2C Peripheral not under reset
// Configure I2C2: Own Address1 and addressing mode
I2C_NFC->OAR1 = 0; // 0: ADD0: = 0: Interface address. 7-bit addressing mode: don’t care
// 1-7: ADD[7:1]: = 0: Interface address.
// 8-9: ADD[9:8]: = 0: Interface address. 7-bit addressing mode: don’t care
// 10:13:Reserved, must be kept at reset value
// 14: Should always be kept at 1 by software.
// 15: ADDMODE: = 0: 7-bit slave address (10-bit address not acknowledged)
// Configure I2C2x: Dual mode and Own Address2
I2C_NFC->OAR2 = I2C_DUALADDRESS_DISABLE; // 0: ENDUAL: = 0: Dual addressing mode enable
// 1-7: ADD2[7:1]: = FE: Interface address in dual addressing mode
// 8:15: Reserved, must be kept at reset value
//I2C_NFC->CR1 |= I2C_CR1_ACK;
gpio_vConfigI2cSdaIoAsOut();
IO_INACTIVE(I2C_NFC_SDA);
//TODO CN: add delay if needed
IO_ACTIVE(I2C_NFC_SDA);
gpio_vConfigI2cSdaIoAsAf();
// Enable the I2C2 peripheral
I2C_NFC->CR1 |= I2C_CR1_PE; // 0: PE: = 1: Peripheral enable
// Set I2C u32Error None
NFCL_tIICHandle.u32ErrorCode = I2C_ERROR_NONE;
// Set I2C eState Ready
NFCL_tIICHandle.eState = I2C_STATE_READY;
// Set I2C u32PreviousState None
NFCL_tIICHandle.u32PreviousState = I2C_STATE_NONE;
2018-09-18 03:42 AM
I think it is not recognized as ACK, because it is no ACK.
The slave is supposed to pull SDA low while SCL is high.
What you see is IMHO the master switching back the direction of the SDA line.
SDA is output for the 8 data bits, and input for the ACK bits.
2018-09-18 05:03 AM
I though it would be enough for representing an ACK that SDA remains in low while SCL is high, during the 9th SCL pulse. Actually, I changed once the address for checking the slave response and the SDA line was kept high at the 9th SCL pulse, which means that the chip rejected the wrong address.
2018-09-18 06:46 AM
For the 9.th ACK pulse, the master switches SDA from output to input before clocking the pulse out.
The pull-up resistors will keep SDA high, resulting in "NO ACK" if the slave does not actively pull it down.
When the ACK pulse is done, he switches back.
2018-09-18 07:35 AM
I saw as well the signals using the STM32446 and the SDA line remained constant in the low level during the 9th pulse (before it too since the last bit of the address is 0). With this controller, the I2C communication works without any issue as I mentioned above. It seems to me really strange since there is absolutely no difference between the I2C modules of the two controllers. Perhaps it is worth to mention that I needed to reset the CR1 after disabling the module because the BUSY flag was stuck at 1. This workaround was not necessary using the 446 controller. Perhaps there is an additional workaround for this issue with the AF flag. Unfortunately this is not mentioned in any erratasheet. Or maybe is it necessary to adapt the value of the pull-up resistors.