Hi Team,
I am working on I2c Bringup on S32K312 chip.
i have made below configurations :
LPI2C0 - Slave configuration - working
LPI2C1 - Master configuration - not working
Configurator changes:
AIPS_SLOW_CLK is the I2c module clock - it is configured as 20MHz.
OS ISR for master is configured -
Problem Statement:
" both I2c SCL and SDA are pulled high always"
even though i can see the I2c_init is successful and there were few write commands also passed successfully, still there is no clock / data seen on bus.
Please suggest here.
Thanks,
Rekha
i could figure out solution, there was one configuration missing. post that change i am able to see the start bit on bus but then bus goes idle. throws error callback with arbitration error. Need your help to resolve this issue.
Hi @rekhak
The arbitration error you are seeing usually means that your device lost control of the I2C bus, which can happen if more than one master tries to communicate at the same time.
Do you have multiple master devices on your I2C bus? If so, it is important to make sure they are not trying to send data at the same time, as that can cause conflicts.
Also, it is a good idea to double-check that your master device is waiting for the bus to be idle before starting any communication. This helps avoid collisions and keeps everything running.
Slave configurations :
Hi @rekhak
I am afraid I am not familiar with Vector DaVinci, so my observations are based on a comparison between the S32DS configurations and the S32K3xx Reference Manual information.
The LPI2C configurations appear generally correct. However, I have one observation regarding the interrupt configuration. Specifically, for the ISR Interrupt Priority parameter, you assigned a value of 144. According to the S32K3xx Reference Manual, there are 16 priority levels, which are configurable using 4 bits in the IRQn fields of the NVIC IPRn registers. Furthermore, based on the NVIC_SetPriority() function, only the upper 4 bits of the 8-bit priority field are implemented, meaning that only values from 0 to 15 are valid.
For clarity and maintainability, it is recommended to use values within the 0–15 range directly.
Additionally, could you please confirm whether the same configuration works correctly for LPI2C0? From what I can see, there does not appear to be an issue with the current configuration, so verifying its behavior on LPI2C0 could help us rule out a direct issue with LPI2C1.
BR, VaneB