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.

TDA4VM: Multiplexed mcu timer as a grabber with false touch issue

Part Number: TDA4VM

Hi team,

Here's an issue from the customer may need your help:

The customer multiplexed the mcu timer[4:9] as a grabber to capture the MCU_TIMER_IO[0:9] minutes. When the capture is started, first toggle TIMER IO, and then enable the timer capture. After some time, turn off the timer capture and read the value. While the input signal does not change, 1 to 2 data are captured every capture initiated.

Could you help check what is the reason for this and what should be the correct process? Thanks.

Best Regards,

Cherry

  • Hi Cherry,

    Can you please elaborate on the use case here? 

    While the input signal does not change, 1 to 2 data are captured every capture initiated.

    Also, please mention what input signal are you talking about here?

    Regards,
    Parth

  • Hi Parth,

    Thanks for your help.

    Can you please elaborate on the use case here? 

    It's an Automated Parking Program. Use the capture function as an ultrasonic radar.

    Also, please mention what input signal are you talking about here?

    The input signal is at 10 mcu_timer_io.

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Sorry, I am still not clear on the issue here.

    The customer multiplexed the mcu timer[4:9] as a grabber to capture the MCU_TIMER_IO[0:9] minutes. When the capture is started, first toggle TIMER IO, and then enable the timer captur

    Can you please elaborate what do you mean by grabber here and how these timers are used?

    Regards,
    Parth

  • Hi Parth,

    Can you please elaborate what do you mean by grabber here and how these timers are used?

    The grabber here is the ICU of AUTOSAR, the input capture unit.

    Mcu_timer[4:9] is currently used. The timers are multiplexed with tiperIO as the platform. When Icu_StartTimestamp is set, assign a to the boot IO from the idle mcu_timer list; When Icu_StopTimestamp is set, the corresponding mcu_timer is recycled to the idle list after stopping the hardware.

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Are you using timers from SDK? 
    If yes, can you also mention the SDK version and the example/driver from SDK you me be referring to?

    Regards,
    Parth

  • Hi Parth,

    If yes, can you also mention the SDK version and the example/driver from SDK you me be referring to?

    sdk:    ti-processor-sdk-rtos-j721e-evm-08_00_00_12
    os:    freertos

    SDK example: mcusw/mcuss_demos/profiling/can

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Which ICU (ECAP) modules are you using for the capture? There are 3 ECAP modules supported by the ICU driver currently.

    It looks like you have more inputs than ICUs, so this is why you have multiplexed the different timer modules to the ICUs?

    In the example, you mention that you are seeing 1-2 data captures while the timer is not running. Could you explain the code process for this:

    Mcu_timer[4:9] is currently used. The timers are multiplexed with tiperIO as the platform. When Icu_StartTimestamp is set, assign a to the boot IO from the idle mcu_timer list; When Icu_StopTimestamp is set, the corresponding mcu_timer is recycled to the idle list after stopping the hardware.

    So when you start Icu_StartTimestamp(), you assign one of the timers to the ECAP module using "tiperIO", can you elaborate what this hardware is? Do you have some reference code we can take a look at to better understand the usage of the Icu driver?

    Thanks,

    Erick

  • Hello Erick,

    Thanks for your support.

    There are 3 ECAP modules supported by the ICU driver currently.

    Yes, while they need 12. The MCU is temporarily doing 10. These 10 modules are fully captured with mcu_timer hardware, and is not related to ECAP. The source code is as follows:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    #define MULTIPLEX_ICU_TIMERS
    #define MCU_TIMER0_BASE (0x40400000UL)
    #define ICU_BASE_TIMER0 (0x02400000UL)
    #define ICU_BASE_TIMER1 (0x02410000UL)
    #define ICU_BASE_TIMER2 (0x02420000UL)
    #define ICU_BASE_TIMER3 (0x02430000UL)
    #define ICU_BASE_TIMER4 (0x02440000UL)
    #define ICU_BASE_TIMER5 (0x02450000UL)
    #define ICU_BASE_TIMER6 (0x02460000UL)
    #define ICU_BASE_TIMER7 (0x02470000UL)
    #define ICU_BASE_TIMER8 (0x02480000UL)
    #define ICU_BASE_TIMER9 (0x02490000UL)
    #define ICU_BASE_TIMER10 (0x024A0000UL)
    #define ICU_BASE_TIMER11 (0x024B0000UL)
    #define ICU_BASE_TIMER12 (0x024C0000UL)
    #define ICU_BASE_TIMER13 (0x024D0000UL)
    #define ICU_BASE_TIMER14 (0x024E0000UL)
    #define ICU_BASE_TIMER15 (0x024F0000UL)
    #define ICU_BASE_TIMER16 (0x02500000UL)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks and regards,

    Cherry

  • Hi,

    May I know is there any update? Thanks.

    Regards,

    Cherry

  • Cherry,

    Could you get a trace to see if there is anything the ICU is reading, with an oscilloscope or something else? Or perhaps a simpler test is to see if you still see readings when the ICU is disconnected from any of these peripherals? This way we can isolate that the ICU is not making random readings itself.

    Regards,

    Erick

  • Hi Erick,

    Now 6 mcu_timer[4:9] and 9 mcu_timer_io[0:9] are being used. 

    All ten inputs can be captured, but the frequency is less than 550 hz to capture the bilateral edge, otherwise only the period is captured. When the signal is not linked, io[0:5] does not interfere and io[6:9] always captures a value. The priority has been adjusted to 0, but there has been no significant improvement. The oscilloscope tracks the signal and the hardware guarantees a signal input of 1% duty cycle of 10khz and full high and low to the tda4 pin signal. The code above has been tuned for troubleshooting and the algorithm is unchanged.

    Thanks and regards,

    Cherry

  • Hi Cherry,

    One thing to clarify, we do not support the ICU Driver from MCAL/AUTOSAR for the timer input captures. Where did the customer get this driver from? Our MCAL driver has support for ECAP, did they make an MCAL driver themselves using the Timer?

    Regards,

    Erick

  • Hi Erick,

    Thanks. It has been confirmed that they don't use <sdk>/mcusw/mcal_drv/mcal/Icu, the code above is from the customer.

    Thanks and regards,

    Cherry

  • Cherry,

    Thanks for confirming. Now that we are on the same page, can you re-summarize the issue the customer is seeing with their usage of the timers? Is this suspected to be an issue with their configuration in hardware? Or with SW provided by TI?

    Regards,

    Erick