CLEV6630ARD on RT1060 + FreeRTOS

[nxf83179]

Hello, everyone! I am currently involved in a project that uses the mentioned board (CLRC663 on Arduino type header, used as NFC frontend). The NFC frontend can either connect to the RT1060 EVK on its Arduino header or using the Camera Signals header (using a ribbon connector and an FPC connector in between this header and the NFC board). 

We have a code-base for NFC that is working on the Azure RTOS project with both Arduino header and CS header. When switching to the FreeRTOS project, the Arduino header works as intented, but the CS connection doesn't work.

I would like to mention that the pinmux and pin init/pin definition is basically the same, from a hardware perspective there is no change between these two projects. From a software perspective, I had to change only the phOsal layer, all the drivers are the same. 

The documentation for this particular NFC IC is pretty sparse and I wasn't able to find any SDK examples with this working on FreeRTOS + RT1060.

I also made some captures using a logic analyzer.

Best regards,

Mihnea 

[Fabian_R]

Hello, this is Fabian

I'm very sorry for not answering you back earlier.

I'm going to guess that you are currently using the NFC front end (CLEV6630ARD).

Since our typical development boards for frontends typically have an LPC1769 in the same EVK connected through SPI, the CS connector is an unknown interface to us but, I'm with you, this shouldn't produce the communication issues reported

Additionally, None of our NFC Frontends have an SDK but, our NFC Reader Library examples are built on top of FreeRTOS. A good porting guide of an i.MX RT1050 is available in the following community link: https://community.nxp.com/t5/NFC-Knowledge-Base/NFC-Reader-Library-Porting-to-i-MX-RT1050/ta-p/11213...

There is something I'm not understanding:

Why in the Azure session, the PDOWN pin state is constantly changing? This doesn't make sense for a working application.

[nxf83179 · Accepted solution]

Hello, Fabian! Indeed, the Azure code is pretty much stripped of functionalities in comparison to the right FreeRTOS implementation. The solution that we found, was to modify the PHOSAL_MAX_DELAY, which was used inside phOsal_EventPend, in phhalHw_Rc663_WaitIrq() function.

Now the application works in the intended way. If you have any comments about this modification, feel free to tell me. Otherwise, I will mark this as solution and close this topic.

Best regards,

Mihnea