• State
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 42 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28388D: [TMS320F28388D] Limitation on frequency interrupt triggered by eCAP or hrCAP module

Audrey Lechat
Prodigy 10 points

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hello,

I am using a TMS320F28388D board from Texas Instruments. I develop the software with MATLAB Simulink. Here is the following software environment:
MATLAB 2025b
TI C2000 Code Generation Tools 22.6.0
TI ARM Code Generation Tools 20.2.7
TI Code Composer Studio 20.0.1.00004
TI C2000Ware 5_02_00_00
ti-cgt-c2000_22.6.0.LTS
ti-cgt-arm_20.2.7.LTS

The CPU clock is 200 MHz.


I use this board to detect rising edges of a squared signal thanks to an eCAP module. The signal frequency is 1.0152 MHz. I use the 6th eCAP module wich is set to monitor input 1. I configure the input X-BAR to route input 1 and the GPIO 37 where my 1.0152 MHz signal is plugged. In addition, the eCAP module works in continuous mode, captures only one event (a rising edge) and triggers an interrupt on capture event 1. This interrupt triggers a task. First, this task switches on a GPIO, then performs diverse operations and finally switches off the GPIO. This GPIO monitors the trigger time and the execution duration of the task. The model deployed on the CPU1 implements the eCAP module and the CPU2 model only makes a LED blink.

I monitor the GPIO with an oscilloscope and I notice that the task is not triggered regularly (see capture in attachment, where the blue signal is the signal at 1.0152 MHz monitored by the eCAP module and the green one is the GPIO, please do not take care of the other signals).
screenshot_oscilloscope.png
So I am wondering if the eCAP module can capture such fast signals?

I tried to use the hrCAP modules as well but I noticed the same behavior. I also tried to permute the CPU1 and the CPU2 models (to execute the CPU1 model on the CPU2 and so on) but I also noticed the same behavior.

I also contacted Mathworks first and they suggest me to contact your team.

If you need more information, please do not hesitate to ask me.
Thanks
Regards

Audrey L.
Control engineer at THALES

  • 0
    TI__Intellectual 920 points

    Hi,

    Please refer to datasheet section 7.12.1.2 eCAP Electrical Data and Timing for maximum frequency that can be measured.

    Please note that the task also takes some time to perform (switching GPIO ON and OFF) and hence using this method ( GPIO truning  to conclude that eCAP is not able to measure the required frequency is not the correct approach. 

    Please refer to examples given in sdk:sdk_loaction\C2000Ware_6_00_01_00\driverlib\f2838x\examples\c28x\ecap for more details. 

    Thanks,

    Divesh

  • 0 in reply to Divesh Dang 18431815
    Prodigy 10 points

    Hi,

    Thank you for these insights.

    In my results, I noticed that the GPIO is not turning on consistently. This is the first time I have observed this behavior. Do you know what could be causing it?

    Regards,

    Audrey

  • 0 in reply to Audrey Lechat
    TI__Intellectual 920 points

    Hi,

    I think that the next interrupt is getting generated while the ISR is being serviced. This might be a reason of GPIO not turning on consistently. Rather than using GPIO, you may try comparing the CAP register with the expected result.

    Thanks,

    Divesh