Hello 234,
Sorry, it is the definition of I2C that slaves must 'pull' the clock-line low to 'pace' a master when return-data is not immediately available. And in ALL cases of microcontroller I2C slave implementations, they ALWAYS pull the clock-line low at every access as uC firmware must supply the return data 'after some time'. Once you have initialized the S32G into I2C 'slave' mode, you are going to have to be sure that it is ALWAYS 'ready' to return data for I2C transactions addressed to it, else it will indeed permanently stall the whole I2C bus. If you don't want the S32G reacting to such transactions, you have to disable this slave mode (for at least those time periods). Does your S32G respond to addressed transactions 'fully normally' when properly enabled?
Regards
Hello 234,
Sorry, it is the definition of I2C that slaves must 'pull' the clock-line low to 'pace' a master when return-data is not immediately available. And in ALL cases of microcontroller I2C slave implementations, they ALWAYS pull the clock-line low at every access as uC firmware must supply the return data 'after some time'. Once you have initialized the S32G into I2C 'slave' mode, you are going to have to be sure that it is ALWAYS 'ready' to return data for I2C transactions addressed to it, else it will indeed permanently stall the whole I2C bus. If you don't want the S32G reacting to such transactions, you have to disable this slave mode (for at least those time periods). Does your S32G respond to addressed transactions 'fully normally' when properly enabled?
Regards