• State TI Thinks Resolved
  • Locked Locked
  • Replies 24 replies
  • Answers 1 answer
  • Subscribers 35 subscribers
  • Views 587 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Undefined Instruction (PC=0x0) when mixing I2C interrupt and polling modes

Imaoka Daisaku
Intellectual 430 points

Part Number: AM263P4-Q1
Other Parts Discussed in Thread: SYSCONFIG

I have configured the I2C Enable Interrupt settings in SysConfig as follows:
I2C1: Enable (Blocking)
I2C2: Enable (Blocking)
I2C3: Disable (Polling)

With this configuration, when performing I2C control on the same core with the following task structure, an undefined instruction exception occurs:
Task A: Uses I2C1 and I2C2 (calls I2C_transfer())
Task B: Uses I2C3 (calls EEPROM_read/write(), which internally uses I2C_transfer())

When I set a breakpoint at address 0x0 in the debugger, the program stopped at PC=0x0 when the issue occurred (this appears to be a NULL access).

Troubleshooting Results
1. Removed I2C_transfer() call for I2C2
  -> Undefined instruction exception does not occur
2. Unified all I2C1-I2C3 to Enable (Blocking)
  -> Undefined instruction exception does not occur
3. Unified all I2C1-I2C3 to Disable (Polling)
  -> Undefined instruction exception does not occur

Based on the above results, the exception appears to occur only when:
- Interrupt Enable settings are mixed (I2C1/2: Enable, I2C3: Disable)
- Multiple I2C instances are used concurrently from multiple tasks

Questions
1. In the I2C driver, is mixing Enable Interrupt settings across I2C instances within the system (e.g., I2C1/2 with interrupts enabled, I2C3 with interrupts disabled) unsupported or prohibited by specification?
2. In configurations with interrupts enabled, is it possible to mix "Blocking" and "Callback" transfer modes?
Note: I am using AM263Px MCU+ SDK 09.02.00

  • 0
    TI__Mastermind 26460 points

    Hi Imaoka,

    I have looped in the I2C expert for this device, please allow them 1-2 days to respond.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Genius 13629 points

    Hi Imaoka,

    When you mix interrupt-enabled (I2C1/I2C2) and polling mode (I2C3) configurations:

    1. A race condition occurs between the interrupt handler and polling loop
    2. currentTransaction becomes NULL in certain timing scenarios
    3. The interrupt handler dereferences NULL → crash at PC=0x0

    Answers to Your Questions:

    1. Is mixing Enable Interrupt settings unsupported?
      1. YES - Mixed configurations expose this driver property. While not explicitly documented as prohibited, it's effectively unsupported due to this defect.
    2. Can "Blocking" and "Callback" modes be mixed?
      1. YES - But ONLY when all I2C instances use the same interrupt setting (all enabled OR all disabled).

    Recommended Solution

    • Immediate Fix (No code changes): Configure all I2C instances uniformly in SysConfig:
      • Option A: I2C1, I2C2, I2C3 → ALL Enable Interrupt (Blocking)
      • Option B: I2C1, I2C2, I2C3 → ALL Disable (Polling)

    Regards,

    Brennan

  • 0 in reply to Brennan Hartigan
    Intellectual 430 points

    Hi Brennan,

    We implemented the changes you recommended, but the issue was not resolved. The results are as follows.

    Results
    　Option A (ALL Enable Interrupt (Blocking)): PC = 0x0 (undefined instruction exception) occurs
    　Option B (ALL Disable (Polling)): No issue

    Verification
    　In the generated ti_drivers_config.c, we confirmed that enableIntr = 1 in gI2cHwAttrs[] for all I2C1/2/3 instances. Therefore, we believe the SysConfig changes are correctly applied.

    Questions
    ・Is there any additional required configuration outside of SysConfig?
    　In SysConfig, we set the following for TI DRIVERS → I2C → CONFIG_I2C1/2/3:
    　Enable Interrupt: ON
    　Transfer Mode: Blocking
    ・In AM263Px MCU+ SDK 09.02.00, are there any known issues or limitations when using I2C with interrupts enabled (Blocking mode)?

    Regards,

    Imaoka.

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    Would it be possible to share the SysCfg files? I can take a better look at the config and help with this.

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi Pranav,

    We have sent the Sysconfig file separately by email.
    We apologize for the inconvenience, but we would appreciate it if you could provide your response by the end of today.
    Regards, Imaoka
  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    I am trying to reproduce the issue at our my end to debug this. This scenario hasn't been observed by me before. I am looping in the module owners internally to help debug this. 
    Sorry for the delay. 

    Regards, 
    Pranav Siddappa 

  • 0 in reply to Pranav Siddappa
    TI__Expert 3236 points

    Hi Imaoka, 

    Imaoka Daisaku said:
    2. Unified all I2C1-I2C3 to Enable (Blocking)
      -> Undefined instruction exception does not occur

    Imaoka Daisaku said:
    Option A (ALL Enable Interrupt (Blocking)): PC = 0x0 (undefined instruction exception) occurs

    I am confused to as to when the exception occurs. Can you clarify the situation?

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav 

    Here is a summary of the situation.

    Environment: AM263Px MCU+ SDK 09.02.00
    Task A: Uses I2C1 and I2C2 (calls I2C_transfer())
    Task B: Uses I2C3 (calls EEPROM_read()/write(), which internally uses I2C_transfer())

    Test Results with First Reported Code (as of 2026/2/16)
    ・Interrupt and polling mixed: an undefined instruction exception occurred. (QA indicated this combination is not supported.)
    ・All interrupt blocking: No issues
    ・All polling: No issues

    Test Results with Second Reported Code (as of 2026/4/6)
    ・All interrupt blocking: an undefined instruction exception occurred.
    ・All polling: No issues

    Narrowing Down the Conditions
    ・To investigate the cause of the undefined instruction exception, we set a breakpoint at address 0x0 and it broke at 0x0.
    ・Even with the same code, the issue does not occur when adding one line of logging or inserting a sleep.
    ・The issue does not occur when the I2C2 call is removed.

    　→ Whether the issue occurs or not appears to depend on the execution timing of I2C_transfer() for I2C2.
    　　(The first reported code may not have encountered the issue simply due to timing.)

    Additional Findings
    We found a separate bug in our implementation where i2cWriteTransaction.timeout was set in tick units instead of microseconds.
    According to the following E2E thread, the timeout should be specified in microseconds in SDK 9.2:
    e2e.ti.com/.../mcu-plus-sdk-am263x-i2c-hld-timeout

    Test results:
    　1us (we intended to set 1000us converted to ticks, but it effectively became 1us): NG (PC=0x0 occurred)
    　1000us: OK

    　→Could setting an extremely short timeout value be related to the PC=0x0 issue we are experiencing?
    　　

    Could you please respond by 4/27?

    Regards, Imaoka

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    Here are my observations based on your summary:

    • Since the behavior is not consistent, high chance this could be caused by synchronization issues between I2C instances
    •  Since it might be due to synchronization, adding a longer delay/logging might avoid it in your case
    • Can you share a screenshot of the logs which showcase that its a PC=0x0 error?
    • Meanwhile i am checking internally if this synchronization is caused due to driver's inefficiency

     Sorry for the delayed response, i was OOO hence couldn't get to it. 

    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav

    I’ll share a screenshot showing the “PC=0x0” error.

    Could you please respond by 5/11?

    Regards, Imaoka

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imoaka, 

    I will look into it. Did adding a longer delay fix the sync issue?

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav

    >I will look into it.

     ->Would it be possible for you to share the results of your investigation by May 20?

    >Did adding a longer delay fix the sync issue?

     ->Yes.After adding a delay, the issue no longer occurs.

    Regards, Imaoka.

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    I am OOO till 20/05. Please expect a delay in response. 

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav

    We would like to inquire about the current status of your investigation.
    We would greatly appreciate it if you could kindly share any updates or progress.

    Regards, Imaoka.

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    Even after multiple attempts, I am not able to replicate the exact issue at my end. Since you mentioned that this is not a consistent recurring issue, this might be difficult to recreate. 

    Imaoka Daisaku said:
     ->Yes.After adding a delay, the issue no longer occurs.

    Glad to know that adding a delay helps fix the issue.

    Is a real EEPROM device physically connected to I2C3 during the tests, and is it responding normally (ACKing transfers)? This detail will help confirm whether the timeout unit correction is sufficient or whether there is something additional to investigate.

    In case you want to inspect the issue in detail, i might need to investigate the application code you are using. Can you share the application code using which i can reproduce this issue?  

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav

    >Is a real EEPROM device physically connected to I2C3 during the tests, and is it responding normally (ACKing transfers)?

    Yes. During the tests, an actual EEPROM device is physically connected to I2C3. Also, EEPROM_write() completes successfully, and we have confirmed that we can write arbitrary data to the EEPROM and that the read-back data matches. Therefore, we believe the EEPROM is returning ACKs and responding normally.

    >Test Results with Second Reported Code (as of 2026/4/6)
    >・All interrupt blocking: an undefined instruction exception occurred.
    >・All polling: No issues

    I will send the code used for the above verification in a separate email, so please continue the investigation.
    If possible, could you share the investigation results by June 1?

    Regards, Imaoka.

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    Sure, i will take a look at the code and try to produce it at my end. Please do drop a reply here once you have sent the code via mail, to notify me. 
    Will try to give you an update as soon as possible.

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav

    The code sent to the TI Japan support team.

    I have requested that it be forwarded to Pranav, so please review it once you receive it.

    Regards, Imaoka.

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    I have received it. Will update you as soon as possible. 

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    TI__Expert 3236 points

    Hi Imaoka, 

    The project you sent, doesn't seem to be building on mysetup. I am using SDK 9.02.00 with ti-cgt-armllvm_3.2.2.LTS compiler and SysCfg-1.20.00. Let me know if the environment required is different.
    Also, I believe you have applied patches on top of the standard 9.02.00 SDK. Could you please share them as well? 

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav

    We understand that the translated patch file has been forwarded to you through the TI Japan support team.
    We would appreciate it if you could kindly provide us with any updates regarding the progress.

    Regards, Imaoka.

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imaoka, 

    I have received the patch files. I managed to build and run the demo in RAM mode. I didn't observe any except which resets the PC register to 0x0. I am yet to test it in FLASH mode.
    Is the issue only observed when you flash the demo on the device in FLASH mode?  

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Intellectual 430 points

    Hi,Pranav

    We were able to reproduce the issue when the demo is programmed onto the device and run in FLASH mode. On the other hand, we have not tested RAM mode on our side, so it is unclear whether it occurs only in FLASH mode.

    Could you please respond by 7/3

    Regards, Imaoka.

  • 0 in reply to Imaoka Daisaku
    TI__Expert 3236 points

    Hi Imoaka, 

    I have different observations while running the app you shared in FLASH mode. I ran the app on AM263px-LP, it ran without any issue.
    Would it be possible to have a debug call, then we can help better? 

    Regards, 
    Pranav Siddappa