• State
  • Replies 1 reply
  • Subscribers 83 subscribers
  • Views 26 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28388D: Unexpected Detection of Short Pulse Despite GPIO Input Qualification on F28388D

Javier Fernández
Prodigy 10 points
Part Number: TMS320F28388D

Tool/software:

Hi TI team,

I'm using the TMS320F28388D and trying to filter short pulses using the GPIO input qualification feature. Here's my setup:

  • GPIO configured with input qualification mode 01 (3 samples).
  • Qualification period set to 255, expecting a sampling window of ~10.2 µs.
  • Configuration is done by CPU1, as required.
  • GPIO ownership is then transferred to CPU2, which reads the input using the GPxDAT register.

Despite this setup, a 3 µs pulse is still being detected by CPU2. I confirmed that the qualification settings are correctly applied and expected this pulse to be filtered out.

Worth noting: the same input qualification configuration is already used successfully in other parts of the application managed by CPU1, and it behaves as expected there. The issue only appears when reading the input from CPU2.

My understanding is that GPxDAT reflects the qualified input state, so short glitches should be rejected. Is there any reason why CPU2 might be seeing unqualified input values? Could this be due to timing alignment with the sampling instants, or is there a limitation in how qualification interacts with CPU2 reads?

Any insights or clarifications would be greatly appreciated!

Thanks,
Javier Fernandez Cepeda

  • 0
    TI__Expert 3280 points

    Hello Javier,

    For QUALPRD = n, the qualifier samples the pin every 2 * n * SYSCLK cycles (not 2^n). At 200 MHz (T_clk = 5 ns), QUALPRD=255 ⇒ T_sample = 2 * 255 * 5 ns = 2.55 µs per sample. With 3-sample qualification, the input must be stable for = 3 * 2.55 µs = 7.65 µs to flip the qualified state (alignment can add up to one sample). A 3 µs pulse should therefore be rejected if the pin is truly in 3-sample mode.

    If CPU2’s init code \ re-initializes GPIOs, it can silently set the pin back to sync (00) or change the group’s QUALPRD. Please read back and confirm that these registers from CPU2 right before you poll to confirm they are still QSEL=01 (3-sample) and the expected QUALPRD for the correct 8-pin group. Also, verify your pins (GPxDAT) is not inadvertently in ASYNC on CPU2.

    One quick test here is to temporarily switch to 6-sample qualification to increase the minimum recognized width (6 * 2.55 us = 15.3 us). If the false detect disappears, it points to qualification still working but previous settings not in effect on CPU2.

    Best Regards,

    Masoud