• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 99 subscribers
  • Views 559 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.

DRA829J: TDA4

yan yan
Prodigy 215 points
Part Number: DRA829J


Hi support team,

There is a question about I2C that needs your engineer assistance. When using SD card to start R5F MCU1_0, MCU_I2C1 cannot communicate normally after being powered on for a period of time. Observe the waveform. On failure sequence, when start sequence, SDA will low but after that the SCL and SDA signals remain high.

Some notes:

1. When using I2C to read in a cycle of 100ms, the reading is successful three times, and the fourth time it fails, the return code is -1 (Timeout).

2. When using the debugger to download the code, there is no such problem.

3. MCU_I2C0 can communicate normally without such problems.

4. Try I2C two modes, the rate of 100K/400K did not solve the problem.

5. In failure sequence, code call stack is I2C_transfer_v1->I2C_primeTransfer_v1->I2CMasterStart, SDA will be pulled low in start sequence but then SCL and SDA have no output waveform, remain high.

6. Try to disconnect the slave device and stop other cores, the problem is still not solved.

Thanks.

  • 0
    TI__Guru** 113810 points

    Hi Yan Yan,

    When you mention that this doesn't work through SD card, are you using SBL or SPL or some other boot loader?

    Can you please describe your steps in more detail?

    Regards

    Karthik

  • 0 in reply to Karthik Ramanan
    Prodigy 215 points

    Hi Karthik,

    Thanks for your answer firstly.
    Yes, we use spl to start uboot, uboot start Linux and then Linux starts application of r5 core, which is our mcu program.

  • 0 in reply to yan yan
    TI__Guru** 113810 points

    Hi Yan Yan,

    Are you trying this on the TI EVM? 

    If yes, can you please share the procedure to reproduce the issue? So that we can debug this at our end and suggest what is going on?

    Regards

    Karthik

  • 0 in reply to Karthik Ramanan
    Prodigy 215 points

    thx, now i'm trying on this

  • 0 in reply to Karthik Ramanan
    Prodigy 215 points

    Hi Karthik,

    We try this on TI EVM, MCU_I2C0 is OK while MCU_I2C1 is not OK. It seems that MCU_I2C1 is not used onTI EVM.

    Our board use pin WKUP_GPIO0_8 as MCU_I2C1_SCL and WKUP_GPIO0_9 as MCU_I2C1_SDA. When error happened, register CTRLMMR_WKUP_PADCONFIG56 bit MUXMODE is 0 and CTRLMMR_WKUP_PADCONFIG57 bit is 0. It seems that no exception happens.

    Please help to check. Thanks.

  • 0 in reply to yan yan
    Prodigy 215 points

    Hi Karthik,
    Sorry for that i mistake register for Pinmux of WKUP_GPIO0_8 and WKUP_GPIO0_9. It should be CTRLMMR_WKUP_PADCONFIG52  and CTRLMMR_WKUP_PADCONFIG53. When defect happen, bit MUXMODE of CTRLMMR_WKUP_PADCONFIG52CTRLMMR_WKUP_PADCONFIG52 will change to 7. 

    In my opinion, There are two conditions for this. One is init failure, but it is confused that after init, MCU_I2C1 can communicate success for a few moment. The other is this bit was writed after init, but it is confused that write breakpoint did not hit.

    It is weried and we will use MCU_I2C1 and change pin state back once defect happend. Hope you can explain this, Thanks.

  • +1 in reply to yan yan
    TI__Guru* 77914 points

    Hi Yan Yan,

    Apologies for delay here. Is this problem still there?

    If so then I just read though and seems like your PADCONFIG registers are being written by Linux and that is why it works till the point Linux is loaded and then the Pinmux value is changed.

    Can you do one experiment where you halt at u-boot and see if things are working as expected? The MCU1_0 firmware will already be loaded from R5 SPL and hence when you halt at u-boot it will already be running.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Prodigy 215 points

    Hi Karan,

    Thanks for reply firstly!

    It is worked as expected after u-boot halted. Another question is that how MCU1_0 started? Can you give me a simply introduction of startup sequence? Thanks!

  • 0 in reply to yan yan
    TI__Guru* 77914 points

    Hi Yan Yan,

    The MCU1_0 is loaded by the R5 SPL, R5 SPL running on the MCU1_0 after loading the A72 SPL branches to the MCU1_0 custom application. So once you have halted at u-boot, you basically are running a standalone application (well, almost) on the MCU1_0.

    You can see the booting sequence here - https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/board/ti/j721e/README#n23 (review this and let me know if you need to understand more on this).

    At this point you MCU1_0 runs your app and u-boot is running (but halted) on A72, nothing else is running. So idea is that if in this configuration you are able to run your application on MCU1_0 then there is a system integration problem where the I2C you are seeing an issue with is being either used by some other core or the Pinmux is being overwritten for it.

    When you are halted at u-boot and see the app working fine, you can then run "boot" on the u-boot command line and this will resume the booting sequence. Most likely you will see the issue again.

    For Pinmux being overwritten, it is easy to check, you can dump the registers after booting kernel using the devmem2 command.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Prodigy 215 points

    Hi Karan,

    I got it, Thanks.