RT1064 fsl_kpp driver bug (?)

[jonver]

Hi, 

Experimenting with the fsl_kpp driver from the SDK_2.x_EVK-MIMXRT1064 2.6.1 package.

The keypad driver contains the following example:

in boards/evkmimxrt1064/driver_examples/kpp/kpp.c:

KPP_keyPressScanning(EXAMPLE_KPP, &read_keys[0], CLOCK_GetFreq(kCLOCK_CpuClk));

in devices/MIMXRT1064/driver/fsl.kpp.c:

static void KPP_Mdelay(uint64_t tickets)

{

   while (tickets--)

   {

      __NOP();

   }

}

void KPP_keyPressScanning(KPP_Type *base, uint8_t *data, uint32_t clockSrc_Hz)

{

...

   /* Take 100us delays. */

   KPP_Mdelay(clockSrc_Hz / 10000000);

}

For clockSrc_Hz, the parameter is 600'000'000 (so 600MHz which is the clockspeed)

The tickets parameter becomes 60 (600'000'000 / 10'000'000)

When I measure this delay, I get 980 ns delay instead of 100us (~100x smaller)

What am I missing here? I this a bug in the kpp driver?

plot of the keyPressScanning function (yellow is column, green is the row):

[jeremyzhou]

Hi Jonathan Vervaeke,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
According to your statement, the execution time of the     KPP_keyPressScanning(EXAMPLE_KPP, &read_keys[0], CLOCK_GetFreq(kCLOCK_CpuClk)); is 980 nS instead of 100 uS.
It seems a bit weird, so I was wondering if you can introduce the testing process you did, for instance, evaluation board, IDE, etc.
In addition, I'd like to know whether you had measured the execution time of KPP_keyPressScanning() function to validate this assumption.

TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------