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.

TMS320F28388D: What is the resolution and minimum measurable time(or Maximum frequency)

Genius 5745 points
Part Number: TMS320F28388D

Hi experts,

Please tell me about the F28388D HRCAP mentioned in the original thread.

Q1: What is the resolution and minimum measurable time(or Maximum frequency)? (ns?MHz?)
I'm confused about the relationship values between datasheet and TRM.

Q2: Is it possible to measure a 13.56MHz (50% duty) signal according to the specific regulations?

Use with SysClock = 200MHz, that is, SysClkPrd = 5ns.

From TRM "25.2.4.1 Applying the Scale Factor", I read that it is possible to measure at a minimum of 0.0390625ns = 25575.4MHz (*1).
*1: When HRSYSCLKCAP=HRCLKCAP, 5ns/128=0.0390625ns

However, from the data sheet "7.12.1.3.1 HRCAP Switching Characteristics", I read that it is possible to measure at a minimum of 110ns = 9MHz.
Referring to the data sheet, I thought that 13.56MHz could not be input.

I tried sending a pulse signal to the ControlCard, but it was possible to observe up to about 7MHz, and beyond that, it seemed like the numbers would be strange.
(The waveform may have been distorted, so the observation may not be accurate.)

Best regards,
O.H

  • Hello Hiromichi,

    Q1: What is the resolution and minimum measurable time(or Maximum frequency)? (ns?MHz?)
    I'm confused about the relationship values between datasheet and TRM.

    The minimum input pulse width which can be measure is 110 ns per the datasheet. This means that the input to the eCAP must be at least 110 ns, it will not detect edges less than that duration. So if you had a 9MHz signal you would be able to measure it with the eCAP (1/110ns ~= 9MHz), but if it was 10MHz then you would have issues detecting the proper edges.

    Q2: Is it possible to measure a 13.56MHz (50% duty) signal according to the specific regulations?

    Per the above explanation, no.

    I tried sending a pulse signal to the ControlCard, but it was possible to observe up to about 7MHz, and beyond that, it seemed like the numbers would be strange.
    (The waveform may have been distorted, so the observation may not be accurate.)

    If you're able to isolate this issue from any possible error on the input signal itself, let me know what deviations you see.

  • Hi Omer Amir,

    Thank you for your support. I understand that the limit value is 9MHz.

    BTW, could you please tell me the use case and how to use "HRCAP_convertEventTimeStampNanoseconds()"?

    Consider the following calculation formula as "HRSYSCLKCAP=HRCLKCAP" and "scaleFactor=1", "SysClkPrd=5ns".
    Assuming that a square wave signal of High/Low=220ns (4.545MHz) is input, the calculation result when "RawCount=2" will not be 220ns.

    From TRM "25.2.4.1 Applying the Scale Factor", I read that it is possible to measure at a minimum of 0.0390625ns = 25575.4MHz (*1).
    *1: When HRSYSCLKCAP=HRCLKCAP, 5ns/128=0.0390625ns

    I tried reading the actual source code (hrcap_ex1_capture.c), but I couldn't understand it...

    Best regards,
    O.H

  • Hello Hiromichi,

    BTW, could you please tell me the use case and how to use "HRCAP_convertEventTimeStampNanoseconds()"?

    This function converts the HRCAP time capture from cycles to nanoseconds. From the hrcap.h file:

    Consider the following calculation formula as "HRSYSCLKCAP=HRCLKCAP" and "scaleFactor=1", "SysClkPrd=5ns".
    Assuming that a square wave signal of High/Low=220ns (4.545MHz) is input, the calculation result when "RawCount=2" will not be 220ns.

    The capture register does not store the minimum input width, it stores the number of SYSCLKs. However, because HRCAP is unique in its hardware to account for a better accuracy, the value will not be 22 (the time capture value from the eCAP for something like 110ns). This is the reason that 128 is present in the equation per your earlier screenshot. For a 110ns measurement, you should therefore expect to see 2816 as the timestamp value if the scaleFactor is set to 1 (just as an example, the value is calculated via the below equation).

  • Hi Omer Amir,

    I was mistaken. I understood. Thank you for your kind support!!

    Best regards,
    O.H