Hi,
after waking up I see 3 possible behaviours.
- break out of suspend loop - and every thing is fine,
- reboot with the corresponding boot reason properly set, and
- 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.
------------------------
In order to debug the HF the faulting instruction, related registers and memory have been revirewed.
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:
- What is the expected behavior after wakeup (1) or (2)? See first posting.
- Is the SRAM state preserverd during suspend?
- After wakeup, is it required to wait for something, e.g MLDO? If yes howto wait and for what to wait.
- Before suspend. Is there something to take care before? I currently use phhalpcr_enterlowpower from the Nxp reader library.
- If its an race condition, do you have an idea causing it, even with interrupts disabled?
p.s.: This discussion has bee moved from:
PN7462AU not waking up after standby
