Hi,
after waking up I see 3 possible behaviours.
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:
p.s.: This discussion has bee moved from:
Hello,
Would you please share any code on how you use to enter/exit suspend mode? I will try to reproduce this issue here.
Thanks for your patience!
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi Kan,
sorry for the late answer.
First, in the beginning of my post I described 3 behaviours i have seen, what is the intended behaviour and why? I guess it is (1), correct?
Second, the device runs NXP reader library (backed by FreeRTOS) and uses the following peripherals. Contact, RF, GPIO, USB, SPI Master.
After making sure that all tasks are able to suspend, to enter low power mode basically using library calls (see snippet below). I will try to reduce the example to figure out what is actually happening, and to be able to hand you more information.
I tried to suspend all tasks/disable interrupts/scheduler in many variations.
Also interesting, I tried to enable the WakeUpTimer to repetitively wake and suspend the system. During the experiment the usb port is kept in suspended state. -> same issue after a couple if suspend/wake cycles I see the crash.
thanks and kind regards
Martin
LPM activation snippet:
static const phhalPcr_RfLdtParams_t rfld_cfg = { .bRfldRefLo = 2, .bRfldRefHi = 3, .bEnableAdvancedRFLD = 0, .bPadding = 0, }; static const phhalPcr_WakeUpConfig_t wakeup_cfg = { .wWakeUpTimerVal = 0, // 1000 .bEnableHIFWakeup = 1, .bSmBusAddrResp = 0x0, .bI2CAddr = 0, .bWakeUpTimer = 0, // 1 .bWakeUpRfLdt = 0, .bWakeUpTemp = 0, .bWakeUpPvddLim = 0, .bWakeUpCtPr = 1, .bWakeUpIntAux = 0, .bWakeUpTvddMon = 0, .bWakeUpGpio = 0, .blWakeupVbusLow = 0, }; phhalPcr_EnterLowPowerMode((phhalPcr_RfLdtParams_t*)&rfld_cfg, (phhalPcr_WakeUpConfig_t*)&wakeup_cfg, &prevention_reason);
Hi Martin,
Did you also use phhalPcr_Init() in the test? Would you please share any code regarding this API as well? Thanks for your patience!
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi Kan,
phhalPcr_Init() is called right after startup.
However I think I am onto something. Ensuring that the PCR_IRQHandler is called seems to help. I will execute further tests using more hosts and share my findings.
I do not yet know why. I do not see any steps executed within PCR_IRQHandler that seem relevant. Maybe you have a clue?
kr
Martin
Hi Martin,
Referring to the UM10858, coming out of standby mode the device would restarts from the beginning.
Did you find anything strange in your test? Please kindly let me know if there is any issue.
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi Kan,
I did a lot of testing, and ensuring that the PCR Interrupt is called, seems to fix the problem. The behaviour is now as expected. Application is state (SRAM) is preserved and the application continues execution as expected.
I delayed may until now because I also wanted our customer to check the patch (everything seems good)
thanks for your help
Martin
You are welcome! Please kindly let me know if there is any further question.
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------