This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM263P4-Q1: After a software reset via WDT, reading from the EEPROM (I2C communication) fails.

Part Number: AM263P4-Q1

After the WDT (Watchdog Timer) fires and the software is reset, the first call to the EEPROM_read function causes the program to halt in the loop (see below) within the I2C_lld_primeTransferPoll function in i2c_v1_lld.c.

This phenomenon occurs approximately once every 10 times.

Please tell me the possible causes and countermeasures (such as what should be done after each software reset).

Note: The SDK used is AM263Px MCU+ SDK 09.02.00.

An inescapable loop:
               /* wait for bus busy */
                while((status == I2C_STS_SUCCESS) &&
                (I2CControllerBusBusy(object->baseAddr) == 0))
                {
                    if ((   object->Clock_getTicks() - object->startTicks) >
                            object->Clock_usecToTicks((uint64_t)(object->currentMsg->timeout)))
                    {
                        status = I2C_STS_ERR_TIMEOUT;
                    }
                }

  • Hi Imoaka, 

    Can you elaborate on what you are trying to do here? How often are you using WDG to trigger a software reset? Does your software reset include module de-init and re-init? Can you also clarify if the WDG triggers a reset mid transaction with the EEPROM?

    Regards, 
    Pranav Siddappa

  • Hi Pranav,

    > How often are you using WDG to trigger a software reset?

    For verification, we intentionally use WDG to trigger a software reset, and resets do not occur otherwise.

    > Does your software reset include module de-init and re-init?

    De-init is not performed. Re-init is performed after a software reset.

    > Can you also clarify if the WDG triggers a reset mid transaction with the EEPROM?

    Yes, WDG can trigger a reset during a transaction with the EEPROM. Also, power supply to the external EEPROM is maintained during the reset.

    Regards,

    Imaoka

  • Hi Imoaka, 

    Yes, WDG can trigger a reset during a transaction with the EEPROM. Also, power supply to the external EEPROM is maintained during the reset.

    The reset being triggered mid transactions might be the issues here. When you perform a software reset, the I2C master will get reset however the target [external EEPROM] still expects to complete the ongoing transaction which is not happening. Hence it holds the line not allowing new transfers. 

    After a software reset, can you reset the EEPROM as well? 

    If this doesn't fix it, you can deinit the I2C controller as well. This will allow you to start a new transaction when both the controller and target are ready to engage in a fresh transfer.  

    Regards, 
    Pranav Siddappa

  • Hi Pranav,

    After a software reset,I called I2C_deinit() before initialization, but it didn't resolve the issue. (The program halt in the same loop as before.) Could you please provide the specific procedure for resetting the EEPROM?

    Also, could you please tell me how to deinit the I2C controller?

    Regards,

    Imaoka.

  • Hi Imaoka, 

    Can you check if the I2C Clk/Data line is held low when the program is stuck?
    If it is held low indefinitely, its due a bus fault. The EEPROM as the target expects more data when the transfers is terminated by Wdg performing a reset. Since it expects more data, it will hold hold the line now and cause a bus stuck situation. 

    You can refer to this doc for the fix in case it is a bus stuck: https://www.ti.com/lit/an/scpa069/scpa069.pdf?ts=1775813319637&ref_url=https%253A%252F%252Fwww.google.com%252F

    Regards, 
    Pranav Siddappa