PN7462 hardfault handler issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PN7462 hardfault handler issue

6,403 Views
mravi
Contributor III

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

14 Replies

295 Views
lojigik472
Contributor I

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. 

0 Kudos

3,726 Views
wadephillip
Contributor I

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!

0 Kudos

5,518 Views
estephania_mart
NXP TechSupport
NXP TechSupport

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 

0 Kudos

5,455 Views
mravi
Contributor III

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

0 Kudos

5,338 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello, 

If you debug the project, what it's the last thing called before that phhalRf_Event_DeInit

Regards, 

Estephania 

0 Kudos

4,370 Views
mravi
Contributor III

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?

0 Kudos

4,294 Views
Ray_V
Contributor V

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.

4,020 Views
mravi
Contributor III

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.

0 Kudos

3,468 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello,

Is this reproducible in our boards? Did you make another modification to the code? 

Regards,

Estephania 

0 Kudos

3,344 Views
mravi
Contributor III

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? 

0 Kudos

3,125 Views
estephania_mart
NXP TechSupport
NXP TechSupport

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 

0 Kudos

3,051 Views
mravi
Contributor III

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.

0 Kudos

2,824 Views
estephania_mart
NXP TechSupport
NXP TechSupport

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

0 Kudos

2,753 Views
mravi
Contributor III

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.

0 Kudos