• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 169 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AWRL6432: I2C failure in the 400kHz

Taeheon Song
Prodigy 90 points
Part Number: AWRL6432

Tool/software:

Hi,

I am currently testing I2C communication using SDK. The environment is as follows.

- motion_and_presence_detection example of the MMWAVE_L_SDK_05_04_00_01

-  AWRL6432BOOST

- Connected with our I2C Test kit

- lowPowerCfg = 0

And I added a task for the I2C communication. Currently the I2C task has higher priority.

I tested alternately between 100kKz and 400kHz. As a result, It doesn't work properly at 400kHz. 100kHz works fine.

After deleting all the radar task, I2C is ok at 400kHz.

And, Rarely, it succeeds when I added vTaskDelay to the middle of the codes of a radar-related.

How to solve this problem.

Best Regards,

Taeheon.

  • 0
    TI__Intellectual 2220 points

    Hi Taeheon,

    Thanks for posting your question on E2E. Please allow us a day or so for our software team to respond.

    Regards,
    Deexith. 

  • 0 in reply to Voona Deexith
    Prodigy 90 points

    Hi,

    I think that It was interrupt priority problem.

    When I set like below:

    in interrupt.c file

    int32_t mmwDemo_registerFrameStartInterrupt(void) {

    ..

    hwiPrms.priority    = 7; //added for test

    ..

    }

    And in i2c_v0.c file

    I2C_Handle I2C_open(uint32_t idx, const I2C_Params *params) {
    ..
    hwiPrms.priority = 5; //added for test
    ...
    }
    It works well at 400kHz as well as 100kHz.  
    One concern is whether other interrupt priorities might cause side effects.
    I'm wondering if there is a recommended priority.
    From our perspective, I2C should have higher priority than radar processing.
    Also, I'm curious about the interrupt priorities specified in the MMWAVE_L_SDK_05_04_00_01.
    Regards,
    Taeheon.

  • 0 in reply to Taeheon Song
    TI__Expert 7635 points

    Hey Taheon,

    We don't have a comprehensive breakdown of all the interrupts for each demo, but generally speaking, when adding new interrupts to existing radar demo applications such as the motion and presence detection demo, we recommend setting the interrupts to the default interrupt priority, 7. This is because there are a few critical interrupts that need to take precedence over all other interrupts for the application to function.

    After adding in a new interrupt, test the project to see if the base application still functions properly and if the new interrupt is serviced correctly. If the application remains functional but the new interrupt is not, increase the priority to see if this resolves the issue. You may also have to adjust the interrupt number for finer priority adjustment i.e., lower intNum = higher importance for interrupts of the same priority.

    Hopefully this helps, but let me know if you have any other questions.

    Regards,

    Kristien