Hi
I am having hard fault handler issue in PN7462. Issue is observed in certain chips and some other are not hitting the hardfault handler ('phFlashBoot_HardFault_Handler'). I am using DoorAccess sample project for development. Issue is observed when standy is enabled only.
When tried to debug , I found that issue happens when an invalid memory access happens. This is when library calls 'phhalRf_Event_DeInit' function. When checked on working chips , I found that this API is not being called.
Can anyone help me in understanding what this API (phhalRf_Event_DeInit) is and when it is being called?
phStatus_t phhalRf_Event_DeInit(void)
{
#if PHFL_PARAM_CHECK >= PH_PARAM_CHECK_SW_RESOURCE
if (gphhalRf_EventGroup == NULL)
{
return PH_ERR(RESOURCE_ERROR, RF);
}
#endif
/* Delete the Event Group */
phRtos_EventGroupDelete(gphhalRf_EventGroup);
gphhalRf_EvtLastSource = E_PH_HALRF_EVT_SRC_NONE;
gphhalRf_EvtLastDest = E_PH_HALRF_EVT_DEST_NONE;
gphhalRf_EvtDetail = E_PH_HALRF_EVT_DETAIL_SUCCESS;
return PH_ERR_SUCCESS;
}
Also the value of 'gphhalRf_EventGroup' is an invalid address and seems it causing the issue.
Please help me in this
Thanks in advance
Midhun
If you are looking for a fun, fast-paced work environment, opportunities for growth, And a chance to make a difference, Then a career at Zaxby’s Careers might be the perfect fit for you.
Hi!
I am having hard fault handler issue in PN7462. Issue is observed in certain chips and some other are not hitting the hardfault handler ('phFlashBoot_HardFault_Handler'). I am using DoorAccess sample project for development. Issue is observed when standy is enabled only.
When tried to debug , I found that issue happens when an invalid memory access happens. This is when library calls 'phhalRf_Event_DeInit' function. When checked on working chips , I found that this API is not being called.
Can anyone help me in understanding what this API (phhalRf_Event_DeInit)is and when it is being called?
phStatus_t phhalRf_Event_DeInit(void)
{#if PHFL_PARAM_CHECK >= PH_PARAM_CHECK_SW_RESOURCE
if (gphhalRf_EventGroup == NULL)
{
return PH_ERR(RESOURCE_ERROR, RF);
}
#endif
/* Delete the Event Group */
phRtos_EventGroupDelete(gphhalRf_EventGroup);
gphhalRf_EvtLastSource = E_PH_HALRF_EVT_SRC_NONE;
gphhalRf_EvtLastDest = E_PH_HALRF_EVT_DEST_NONE;
gphhalRf_EvtDetail = E_PH_HALRF_EVT_DETAIL_SUCCESS;
return PH_ERR_SUCCESS;
}
Also the value of 'gphhalRf_EventGroup' is an invalid address and seems it causing the issue.
Please help me in this
Thanks in advance
Midhun
Hi Midhun,
Based on the information you provided, it seems that the issue you're experiencing with the hard fault handler in PN7462 is related to an invalid memory access when calling the 'phhalRf_Event_DeInit' function. This function is used to delete an event group, and it appears that the value of 'gphhalRf_EventGroup' is causing the issue as it is an invalid address.
It's difficult to say exactly when this function is being called without more context, but it appears to be related to the standby mode. If the issue is only occurring on certain chips, it's possible that there may be a hardware or firmware issue with those particular chips.
I recommend reaching out to the manufacturer or support team for assistance with understanding the function and how it's being used in the DoorAccess sample project. They may be able to provide more insight and help you troubleshoot the issue.
Best of luck!
Hello,
Do you have your custom board?
By any chance, is when is this event set? Could you please check this guide, I believe this might help you understand a little more ho it's the reader library working and the necessary elements.
Regards,
Estephania
Yes.We are using a custom board. But issue is with few boards only. Is there any hardware/software possibilities which can cause this issue?
Firmware have standby enabled (500ms).In issue board ,what we observe is after wakeup ,library named 'libphhalRf_arm-none-eabi.a' calls 'phhalRf_Event_DeInit' fucntion and device is going to Hardfault handler. Inside this function , address of a variable seems invalid and causing the issue.
Also in working boards , this "phhalRf_Event_DeInit" function is not get called.
Also when tested with standby disabled firmware , we are not seeing the issue at all.
The library which calls the function is in "PN7462AU\phHal\phhalRf\lib\" folder
Hello,
If you debug the project, what it's the last thing called before that phhalRf_Event_DeInit?
Regards,
Estephania
Hi
Since standby is enabled in the firmware , I am not able to use the debugger.I am trying with some GPIO toggling to check the flow of code execution.
phhalRf_Event_Init is calling before phhalRf_Event_DeInit, but I am not sure this is the last thing called before phhalRf_Event_DeInit.
Also it seems issue is happening after wake up.
Is there any better way to debug when standby is enabled?
You can try debugging the code when you wake up from standby by setting a loop at the beginning of the function you want to debug.
{ volatile WaitForDebug = true; while (WaitForDebug){ asm volatile("nop"); } }
Then Attach with the debugger without resetting, click "PAUSE", then you can look at the call stack to see where the function was called from.
You can also set WaitForDebug = false and step through the code.
Alternatively you can change your "Standby" function so that it only waits for Event(__WFE()) or Interrupt(__WFI()) instead of going to standby. Then you can run the debugger as you normally do.
Hi , I tried with above method and identified the issue causing section.Details are below.
The issue function calling point identified.At standby ,device will be running with internal oscillator. At wakeup , device will enable external crystal and will check whether 27.12Mhz is available ('phhalClkGen_Clk27m12Detect()' ).If present ,it will switch to it.If it is not there ,it will call HW_tear_down function where it will deinitialise all (RF_deinit).
In issue boards , it is going to this hw tear down function.When checked at the oscilloscope, during the check up time , the 27.12Mhz is not available.After 5 ms around , the crystal clock is showing in oscilloscope.In working boards , crystal clock is coming immediately.
Part number and value of crystal and associated capacitors are same in both working and issue boards.
I have tried replacing the capacitors and crystal from working board to issue board.But still issue is present.
Hello,
Is this reproducible in our boards? Did you make another modification to the code?
Regards,
Estephania
We observed the same in eval kit one time.I will check once more to confirm and update.
Code base is same with following changes
* Standby is enabled( PHFL_ENABLE_STANDBY)
* TVDD 3V monitor enabled (PHFL_ENABLE_TVDD_3V_MON) :
With above changes only also ,I am able to reproduce the issue in issue boards.
In hardware ,we are shorting TVDD_IN ,VUP_TX,TVDD_OUT and VBUS.( Without TXLDO mode). Supply voltage is 3.3V. Any other software configuration is required for using without TXLDO?
Hello,
Please check it.
Also, could you please check the PN7462 family Quick Start Guide ? I found an interesting note in one of our manuals
Could you please check the page 14 about the note on the DPC calibration ?
Regards,
Estephania
Hi ,
I have measured the ITVDD current consumption.The current consumption is between 70mA - 85mA when card is placed.As maximum limit is 250mA , I guess it is safe.Also since we have no issue when sleep is disabled , I guess issue is not related to DPC calibration.
Also I have tried placing one of the issue IC in eval kit.In eval kit also we are able to see the issue with one difference in behaviour. In eval kit , polling is happening till first card detection and after that polling is not happening.
In our issue boards ,after a while polling will automatically stop.
Hello,
So there is an issue with the custom board, but there seems to be also one in code. To verify if the chip it's damaged or not, what happens if you load one of the examples in the evaluation board with one of the chips from the not working board?
Could you please try it?
Regards,
Estephania
Thanks for the info. We will look into DPC calibration and see if it have any impact.
Also is there any way we could know when
'phhalRf_Event_DeInit' function will get called?
I guess this gets called in some error condition.