QN9080 Sleep Flexcomm

[davideferrario]

I am working on a project based on QN9080SIP module and I need to use 4 Flexcomm (1 SPI, 2 I2C, 1 UART).

I am using latest 2.2.3 SDK.

I am facing an issue when I put MCU in sleep.

This is my configuration:

/* Use low power */
#define cPWR_UsePowerDownMode 1
#define cPWR_BLE_LL_Enable 1
#define cPWR_DeepSleepMode 1
#define cPWR_EnableLpTmrRunning 1
#define cPWR_EnablePD0RtcInterrupt 1
#define cPWR_DeepSleepDurationMs 500

The issue that I am facing is that if I run code from SEGGER debugger, everything seems to work correctly.

If I disconnect SEGGER and I repower board, it seems the hardware Flexcomm (but I suppose different hardware devices - ADC and DAC for example) are no more working.

It is hard for me to  investigate the problem, as I can not debug the problem - because of my source code seems to work if I run with debugger attached.

[nxf56274]

Hi,

When you exit the deep sleep mode, try to reinitialize the your flexcomm.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days 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.
-------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

Low power modes don't operate correctly when the debugger is attached so you will need devise a strategy for testing (and incremental testing to identify things that do work correctly and those that don't) without needing the debugger connected.

The main failure potential with low power modes is that clocks that are needed are disabled (some can be configured to be active or not in particular low power modes) or that the low power mode is entered while peripheral activity is still in progress (in which case it needs to be delayed until this activity has terminated).

After using the debugger and switching to 'live' operation a power cycle is recommended to ensure that the new modes can be entered (some things are 'sticky' and so need a power cycle rather than a SW reset).

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/kinetis/LLWU.html