PN7462AU not waking up after standby

[mravi]

Hi ,

We are having issues related to wake up in PN7462AU. This issue is observing in our certain boards and in some other issue is not observed. It seems like device is not waking up after standby call is called. The issue is observed with Door access sample application also.In sample application , we enabled the "PHFL_ENABLE_STANDBY" macro and started running. The polling stops after few seconds due to wakeup issue. Tried to debug the issue using some GPIO toggling and found that after standby call , code is not executing further and not waking up either after timer expiry.

PH_REG_SET_BIT_WO(PCR_CTRL_REG,STANDBY);
/* This portion of the code will be reached only when entering into the standby fails */
dwStbyPrevReason = PH_REG_GET(PCR_BOOT_REG);
*psStandbyPrevReason = (phhalPcr_StandbyPrevReason_t)
((dwStbyPrevReason & PCR_BOOT_REG_STBY_PREV_REASON_MASK) >> PCR_BOOT_REG_STBY_PREV_REASON_POS);

In the above section , code is running upto 'PH_REG_SET_BIT_WO(PCR_CTRL_REG,STANDBY);' . Below code is not executed. But device is not waking up after timer expiry (500mS) . Also when current consumption is measured , it is around 10mA and seems like device is not in standby.

We tried checking EEPROM values and looks OK.

Also when standby is disabled , issue is not present.

Can anybody help us in this ? 

Also is there a better way to debug this ? Since the firmware have standby included , after the standby call  debugger shows error.

Thanks in advance

Midhun

[martin_elshuber]

Hi,

I'd like to tap in into the discussion since I experience similar issues with (in my case) suspend.

After waking up I see 3 possible behaviours.

1) break out of suspend loop - and every thing is fine,

2) reboot with the corresponding boot reason properly set, and

3) HardFault (HF) just after PH_REG_SET_BIT_WO(PCR_CTRL_REG,SUSPEND), or somewhere within phhalPcr_RestorePowerConsumptionChanges.

ad 1, 2) I am a little bit confused that I see both behaviours. I could not find any decisive clues on this in the hardware manual either. So if both behaviours can be expected, what are the reasons for either of them.

ad 3) For me, this is quite concerning, since I have no clue why the HF happens. The HF does not always occur at the same address, but consistently just after PH_REG_SET_BIT_WO(PCR_CTRL_REG,SUSPEND). I tried with PRIMASK set and cleared. I dug into the assembly code, that raises  the HF and could not find a valid reason for the HF to occur.

Can missing to disable some interface before entering suspend cause this issue.

I also tried to wake up with the wakeup timer. In this case the application will enter suspend again. I got the same result. After one ore two wakeup I can see a hard fault.

Setting a breakpoint after PH_REG_SET_BIT_WO(PCR_CTRL_REG,SUSPEND), and hitting continue works, but why?

For your information: I am running custom firmware (with nxp lib and gcc) on a the PNEV462B V2.2 (without any HW changes) and a custom board. Both targets show the same behaviour.

[estephania_mart]

Hello, 

In this case, there will be the need to find the reason why it is entering a hard fault, what it's the last instruction executed before it enters that state.

If the code its custom, have you checked the available documentation regarding the library to help you in the development as well. 

Regards, 
Estephania

[martin_elshuber]

Hi,

thats the first thing that has to be done in such cases.

The HF happens at different places, but always just after wakeup. Most of the time it is an ldr instruction. Checking the corresponding register contents state that accessed address is garbage.

However, looking at the disassembly shows that there should be valid values stored in the parameters of the faulting ldr. (see statement on concurrency below)

For examplew two ldr inst: The first one loads a register address which is stored relative to the pc into, say, r1. The second uses the address in r1 to access the register contents and faults.

There are a couple of other instructions in between, but none of them writes r1.

Checking all participating adresses and registers show that everything looks good except the contents in r1.

It almost seems that the first ldr never got executed, because the "garbage" looks like values the routine had handled just before in r1.

I cannot see the reason for this garbage, sincec concurrency is avoided by disabling IRQs using PRIMASK far before entering suspend, and the ain assembly should force the r1 into a correct state.

There really not much ongoing in this area of the code. So I do not think this is the point. But, I also tried with IRQs enabled.

Not suspending the CPU is a work around (just exit the routine and state host com ongoing as prevention reason). So I really think that it has something to do with suspend.

Also, when adding a breakpoint on the first instruction after suspend, and hitting continue also seems to mitigate the problem.

I know, most of the time HF is a SW issue. But in this case I feel there is something else ongoing. However, I will vontinue checking the code.

Further, I struggle a bit with the manual:

A) What is the expected behavior after wakeup (1) or (2)? See first posting.

B) Is the SRAM state preserverd during suspend?

C) After wakeup, is it required to wait for something, e.g MLDO? If yes howto wait and for what to wait.

D) Before suspend. Is there something to take care before? I currently use phhalpcr_enterlowpower from the Nxp reader library.

E) If its an race condition, do you have an idea causing it, even with interrupts disabled?

thx

Martin

[estephania_mart]

Hello Martin, 

Could you please help me separate all your information in a different post just not to mix the information from the original post and avoid any confusion? 

Regards, 
Estephania 

[martin_elshuber]

Followup Question moved to PN7462AU wakeup after suspend behaviour

[estephania_mart]

Hello, 

Something that it's not clear for me, could you please help me confirm? Are you using your custom boards? Or is this reproducible in our boards? 

Regards, 

Estephania 

[mravi]

Yes .We are using custom boards,issue is seen in few of our boards.Other boards are working fine. Also we are able to reproduce the same issue in eval kit also when we replaced the chip.

[estephania_mart]

Hello, 

Sorry, did you said that you replaced the chips that are causing you a failure in our development board and you still see the issue? If you load one of the available examples of the reader library in those boards with the failing chip, do you have a hard fault? 

Regards, 
Estephania