OS removal in Library software

[smiwa]

Hi,

My question is somewhat general and may be difficult to answer but I need your help!

As my system has no specific OS running, I want to change PN5180 Library software to the one without FreeRTOS functions.

I am trying to modify BasicDiscovryLoop which is controlled by functions like phOsal_xxx in the thread. As I think it does not work only to remove those functions,  could you please let me know how to modify them to Non-OS simple functions?

Thank you for your supports!

Best regards,

   S. Miwa

[smiwa]

Hi Christian san,

Could you let me know more about phOsal_EventPend()?

If I replace it to equivalent process, is it OK that it simply waits until IRQ which is focused at that process is on?

Thank you for your supports!

Best regards,

   S. Miwa

[yen_chen]

Hi @smiwa 

Could you tell me about your phOsal_EventPend() whether it solved or not ?

Your IRQ can be used normally ?

Do you use CLIF_IRQHandler ?

Please let me know .

Thanks!

BR,

Yen

[smiwa]

Hi Christian san

Very sorry that I would like to revise my question before... In it, I wrote "But it seems for me that RF on is started by external trigger." but I have found my observation is not correct.

I traced the function execution sequencially carefully and found that the software waits for IRQ by the function "phhalHw_Pn5180_WaitIrq()" in LPCD search.  That is the reason why I misunderstood that DiscLoop starts by some trigger.

Now I understood DisclLoop start initiatively as you explained.

Thank you very much!

Best regards,

   S. Miwa

[smiwa]

Hi Christian san,

Thank you for the detail explanation and I understood its sequence. But it seems for me that RF on is started by external trigger.

Below is my observations

  1. Put Card on the antenna of evaluation board

; 2  Run the DiscLoop

  3. Nothing happens even if card is in proximity range

  4. Move card slightly (I think it changes electromagnetic field condition to antenna?)

  5. Discloop starts to detect card

  4. After detecting card, Discloop stops and wait for another trigger(card movement)

based on this fact, I guess that PN5180 issues INT to CPU when RF field change and according to it IRQ DiscLoop starts again.

Is this understanding not correct?

Best regards,

   S. Miwa

[christianeisend]

DiscLoop is a higher layer component which performs the discovery of counterparts (like a card or p2p target device) according to NFC Forum or EMVCo specification. So there is a clear sequence on how this detection procedure looks like.

To put it into a nutshell:

1. It turns on RF

2. Waits a few milliseconds (RF on guard time, usually 5ms)

3. Sends out a request frame for first technology (e.g. 14443-3A) and waits for a response from a card which potentially is there

4. Optionally, stops discovery in case an answer has been received and so called bail-out option is set

5. if bail-out is not set or there was no card response, wait again a few milliseconds (depending on enabled discovery loop protocols)

6. Sends out a request frame for next enabled technology (e.g. 14443B) and waits for card response

7. If there was no card response and If no more technologies are available, switch off RF field, wait some milliseconds and go back to 1.

otherwise go back to 4.

This may not be the fully accurate flow since it depends on specifications but it should give you a basic idea.

So, which IRQ is used? Actually, there is only one IRQ line from PN5180 connected to a IRQ-able GPIO of your microcontroller. However, this one iRQ line is software-multiplexed inside PN5180 so it can have multiple sources which are configurable using the IRQ_ENABLE register.

So, you can configure to raise the IRQ line on TxDone or RxDone event, or TimerElapsed event. Actually you don't need to configure, RdLib is doing that. The only thing you need is to ensure is that your microcontroller executes the ISR (IRQ handler) RF_IRQ_Handler in case your controller detects a rising edge on this GPIO.

Christian. 

[smiwa]

Hi Christian san,

I have a question again.

I though PN5180 detect cards after it emit RF but I found in DiscLoop, by another trigger RF on is executed. 

So could you tell me how PN5180 detects card is near field and whta kind of IRQ is issued to the host?

Best regards,

   S. Miwa

[smiwa]

Hi Christian san,

I think I am understanding the IRQ mechanism. Very slowly, I am sorry...

PN5180 issue IRQ --> RF_IRQ_Handler() pick it up -->phhalHw_Pn5180_EventCallback() is called, In its function, phOsal_EventPost() is executed. What kind of job to be processed is determined depending on  bitmask. --> then waiting due to phOsal_EventPend is cleared.

Is this correct?

Thank you for your support!

Best regards,

   S. Miwa

[smiwa]

Hi Christian san,

I revise something about STOP condition in NULLOS configuration.

When it enters "phOsal_EventPend()", it can not loop out from while(1) block shown below. It seems loopout condition cannot be satisfied.

phStatus_t phOsal_EventPend(phOsal_Event_t eventHandle, phOsal_EventOpt_t options, phOsal_Ticks_t ticksToWait,
phOsal_EventBits_t FlagsToWait, phOsal_EventBits_t *pCurrFlags)
{

........................

........................

while(1)
{
/* Enter Critical Section */
phPlatform_EnterCriticalSection();

if ((((options & E_OS_EVENT_OPT_PEND_SET_ALL) && (((*((uint32_t *)eventHandle)) & FlagsToWait) == FlagsToWait))
|| ((!(options & E_OS_EVENT_OPT_PEND_SET_ALL)) && ((*((uint32_t *)eventHandle)) & FlagsToWait)))
|| (gbWaitTimedOut))
{
/* Exit Critical Section. */
phPlatform_ExitCriticalSection();
if (gbWaitTimedOut != 0x01)
{
status = PH_ERR_SUCCESS;
}
break;
}

/* Exit Critical Section. */
phPlatform_ExitCriticalSection();

/* Wait for interrupts/events to occur */
phPlatform_Sleep();
}

........................

........................

}

Should I use those event functions In NULLOS configuration?

Thank you for your supports!

Best regards,

   S. Miwa

[christianeisend]

In fact, you need them also for Null Os configuration - there is no need to change anything in Null OS.

Event handling (using phOsal_Event*) is kind of emulated in Null OS. In fact what happens is that Null OS just uses a global variable (gCurrentEventHandle) and this integer holds a bitmask. phOsal_EventPend just performs 'stupid' busy polling of this bitmask in a loop while phOsal_EventPost sets the bitmask. phOsal_EventPost gets called within IRQ context, by RF_IRQ_Handler and phhalHw_Pn5180_EventCallback.

So in case you say phOsal_EventPend it means that you don't get an interrupt from PN5180 (and, hence, RF_IRQ_Handler() and phhalHw_Pn5180_EventCallback() is not called)

Christian.

[smiwa]

Hi Christian san,

The link error looks solved. I commented out the definition below. (I found the places of multiple definitions.)

   #define xPortSysTickHandler SysTick_Handler in FreeRTOSConfig.h

But its program cannot run correctly. It seems stopped when executing "phPlatform_EnterCriticalSection();"

Though I thought these functions defined in pHOsal_....are no longer used when NULLOS is define, they look still functioning. Can I remove those functions?

Thank you for your supports!

Best regards,

   S. Miwa

[christianeisend]

In case you use Null OS it shouldn't use FreeRTOSConfig.h any longer. I assume you use LPCXpresso IDE - are you still compiling the FreeRTOS project in LPCXpresso? This is not required anymore, just remove it from the project explorer.

In case you don't build FreeRTOS project or it's not in the projects list - do you see from which file FreeRTOSConfig.h is being included?

Christian.

[smiwa]

Hi Christian san,

Thank you for your quick reply! It looks you do not have enough sleep...

For second question, I understood!

Regarding link error, I modified two files(ph_NxpBuild_App.h and ph_NxpBuild_Lpc.h) to change define but I have still the same errors.

Do you have any suggestions?

Best regards,

   S. Miwa

[smiwa]

Hi Christian san,

Regarding to the question (1) that I previously sent, I tried to change FreeRTOS to NULLOS. I have link two errors.

(a) multiple definition of "SysTick_Handler"

(b)"qwLoadValue" is not defined

In freeRTOS configuration, there is no errors.

I think some kind of modification such as #ifdef or so is necessary but I am not sure how to fix them now. Could you please advise me its approach?

Thank you for your support!

Best regards,

   S. Miwa

[smiwa]

Hi Christian san,

Thank you for kind and very good explanation for me to do next action!

Based on your advise, I will try NULL OS configuration. So, I have a question. 

(1) Where should I define it? (I know there are many places where #ifdef NULLOS is written. To completely change the runtime configuration, I think I define NULL OS is employed.)

(2) For another your advise, is there no problem or risk due to the interruption by other events defined in timer handler? For example, when PN5180 is waiting for the response and CPU as well, at the just time card responses, if the timer handler get its time to those job?

Thank you for your support!

Best regards,

   S. Miwa

[christianeisend]

Hi,

there should be a file called ph_NxpBuild_App.h - if you are using the example applications which are part of the library package, this file is located in the sub-folder "intfs" of the respective example. In this file, search for

#define NXPBUILD__PH_OSAL_FREERTOS‍‍

comment this one out and define NXPBUILD__PH_OSAL_NULLOS instead.

#define NXPBUILD__PH_OSAL_NULLOS
//#define NXPBUILD__PH_OSAL_FREERTOS‍‍

On your second question:

There shouldn't be any problem interrupting the reader library by an ISR or timer handler while waiting for card response. PN5180 has a built-in reception buffer which is big enough to receive a full card frame. So card reception is autonomously handled by PN5180 and once the timer handler has finished and execution is back at reader library, the library can read out the buffer from the PN5180.

Hope that helps,

Christian.

[smiwa]

Good morning, Christian san,

Thank you for asking!

Yes, your thinking is just as  I am thinking except we have no RTOS running.

>I understand that you have regular 20ms timer tick, its handler will be used to call the ReaderLibrary API - is it what you are planing?

  --> Yes.

Second, since it is a timer handler/callback, I assume it should run as short as possible and functions called there shouldn't block?

  --> Also, yes. in the handler, I want to do minimum task and the rest will be processed in main loop.

What is your RTOS configuration? Is it only based on such 20ms time slots (so, round-robin scheduling) or is it possible to use dedicated tasks/threads within a pre-emptive/cooperative configuration? 

  --> Our product is very compact 1D/2D barcodereader which has no specific OS and we established simple tasking manager based on 20ms tick. As it already has its tasks for barcode reading process, I want to minimize new task necessary for NFC reading. 

Thank you for your support!

Best regards,

   S. Miwa

[christianeisend]

Hi,

thanks a lot for clarifications and please apologize my delayed answer.

The issue i'm seeing with regards to reader library and your targeted application is that the reader library has a fully synchronous design. This means: You call an API and the function blocks until the requested action is processed.

Let me give you an example: There is an API called phpal14443p4_Exchange which is used to send a data from PN5180 to a card/tag, wait for card's response and return the received card data back to the caller. So this function blocks during PN5180 <-> card data exchange. Depending on the card, the ISO 14443-4 standard allows the card to extend the time it needs to wait to send the response by using WTX (waiting time extensions). So a card response could (theoretically) come only after several seconds, whereas it will be in the 10-100 milliseconds in real applications. Of course, other RF protocols like Felica have different response times defined. But at the end it doesn't change the fact that the reader library APIs are blocking.

So, in case you plan to call reader library functions from within your timer handler, it could happen that the timer handler is occupied for several hundred milliseconds which means it blocks your complete system during that time.

One more thing I would like to add: When saying 'blocking API' it means that the function performs a busy-polling on the interrupt register of PN5180, so during wait of card response the CPU will be 100% occupied by reading out PN5180's interrupt register to see if a card is already there. In case you would use a RTOS then of course the busy-polling is replaced by OSAL_Event functions you were referring to in your first post. For non RTOS these APIs don't need to be implemented and instead you need to use the NULL OS configuration in ph_NxpBuild_App.h (defining

NXPBUILD__PH_OSAL_NULLOS‍

there and undefining the other NXPBUILD__PH_OSAL_ defines)

Coming back to your application: In your case the only solution I see is to have reader library running in the main task (main loop) and all other activities running in the timer handler. Of course, it depends on your software and system architecture if this is possible at all.

Hope that helps,

Christian.

[smiwa]

Hi All,

Does anyone give me any suggestion regarding to this issue?

I think my question may be  too general to answer, so I write again in the detail.

My system has 20msec interval timer system for background processing and I want to move BasicDiscoveryLoop in library to my system.

I want to process the tasks by 20msec timer handler instead of OSAL system such as Osal_EventCreate, Pend, Clear, and etc.. What I want to know is what those OSAL fuctions do and if possible, how to change to simple timer interrupt system. 

I need your help and thank you for your supports!!

Best regards,

   S. Miwa

[christianeisend]

Hi,

please allow me asking some questions upfront, this will help me in understanding your issue in more detail. Based on that I will try to answer your questions.

I understand that you have regular 20ms timer tick, its handler will be used to call the ReaderLibrary API - is it what you are planing?

Second, since it is a timer handler/callback, I assume it should run as short as possible and functions called there shouldn't block?

What is your RTOS configuration? Is it only based on such 20ms time slots (so, round-robin scheduling) or is it possible to use dedicated tasks/threads within a pre-emptive/cooperative configuration? 

Christian.