Hello,
I need to enable, then disable, the frequency carrier of the PN5190 in a very short delay by step of 250µs. An example of what I want to have is on the picture below :
To do that, I use the Nxp API :
(void)phhalHw_FieldOn(phNfcLib_GetDataParams(PH_COMP_HAL)); // enable the frequency
and :
(void)phhalHw_FieldOff(phNfcLib_GetDataParams(PH_COMP_HAL)); // disable the frequency
The PN5190 is connected to a STM32 through the SPI (@500kbs/s) .
Unfortunately, even with the SPI bus at 8Mbs/s, the time to send a command is greater than 250µs. This is due to the communication between master and slave on the SPI bus.
My question is : is there a mean or a configuration of the PN5190 to bypass these SPI exchanges (MOSI -> MISO, IRQ, response, ...)?
(note: It doesn't matter if I haven't an answer from the PN5190 about the status of the command I send. Without a response from the PN5190 is also OK.)
Thanks in advance for your support.
Best regards.
Hello @KellyLi ,
Thank you for your feedback.
First of all, my goal isn't to send some data (ISO 14443 meaning) with this test.I just wish to enable/disable the carrier frequency.
To do that, I prepared a short program to test the carrier frequency enable and then carrier frequency disable. It is summarize here (with explanations after) :
while (1)
{
if (true == bInitPn5190)
{
(void)phhalHw_FieldOn(phNfcLib_GetDataParams(PH_COMP_HAL));
osDelay(50);
(void)phhalHw_FieldOff(phNfcLib_GetDataParams(PH_COMP_HAL));
osDelay(50);
}
osDelay(100);
}
This short program enable the field, wait 50ms before to disable the field. When the field is disabled, a wait time of 150ms (50ms+100ms) is performed before to restart in the infinity loop (while(1)).
With a logical analyzer (SP209 IKALOGIC), I monitor SPI bus and I observe these exchanges (with explanations after):
From a macroscopic point of view, we can observe some "glitch" that are in fact data. This picture isn't relevant for analyzes, but just to check the program is OK. At the maker "1", the carrier frequency field is enabled, and at marker "4" (50ms later), it is disabled. Waiting timings between enable and disable seem to be OK
So, I zoom in at marker "1", where it is the message in charge of to enable the carrier frequency field and I can observe the following (with explanations after):
At the marker "1", I observe the activation of the Chip Select (CS) to activate the PN5190. During this activation, the host (STM32) send the command to the slave (PN5190). Then, before the marker "2", the CS is activated once again and the slave (PN5190) responds to the host (STM32). Note that IRQ is well raised before the PN5190 answers.
Between those 2 markers, there is a little bit less than 2.93ms. But this time is too long in regard of the bit activation I wish that should be 250µs.
Let me know if you need futher informations.
Best Regards.
Hello @MG3
1. It is recommended that you take a look at the following API, it may take a long time here, you can modify the waiting time according to your application.
2. In addition, it is recommended that you use the level change of the GPIO port to detect the API execution time, which is more intuitive. For example, the following logic is for reference.
3. How to optimize the execution time of these two APIs, it is recommended that you step into them, locate the specific point and then find a way to optimize.
Hope above can be helpful to you.
BR
kelly
Hello @KellyLi
About the first point (function "phhalHw_Pn5190_WaitIrq"), it is clear that this function is a blocking call, as it is mentionned into the comment:
This blocking call is confirmed by the GPIO (second point) you propose to monitor to (green signal on the picture above):
About the last point, as this API is provided by Nxp, I have a doubt about a wrong side effect I could generate if I change the behavior of these functions.
Best Regards.
Hello @KellyLi
I don't know how to optimize response time, even by decreasing the IRQ timeout?
As per the "PN5190 - Instruction layer", the sequence to communicate with the PN5190 imposes some rules. The first rule is that a command is always acknowledged by a response (refer to screenshot below).
My question are:
1- Who is the stakeholder involved by the latency added between the question and the response?
2- Is the latency is added by the PN5190 (due to the configuration I apply or somewhat else), how will react the system if there isn't enought time for the reponse?
3- According the "PN5190 - Instruction layer", "host controller is not allowed to send another command before receiving a response to the previous command". Who will react the system if I send another command before to have the response of the previous?
Thanks in advance,
Best Regards
Hello @MG3
It is recommended that you modify this variable check the below screenshot. System adaptation needs to be debugged. NXP provides only a demo, once it is integrated into the user's system, it still needs to be debugged according to the actual situation of the user.
In addition, regarding the three questions you raised, I also recommend that you understand the description of FreeRTOS events and task switching, then your question should have an answer.
BR
kelly
