Possible to fully turn off UART from Zephyr based application?

Hello Devzone Community,

My name is Ted, and I am some way along development of Zephyr based firmware, running on an nRF9160 based custom board.  I'm looking to put the board, including LTE modem and application processor of the 9160 SiP into its lowest, deepest sleep modes.  I have found some posts somewhat related to this question -- 59007 "put-m33-mcu-in-nrf9160-sleep-mode", 66112 "best-possible-strategy-for-deep-sleep-and-awakening", 52450 "nrf9160-low-power-modes---entering-and-measuring-current" and a few additional posts -- but none of them answers key questions I am facing and not finding answers to among Devzone and other Nordic and third party documentations.

There are also some stale links in some of the above posts as they are sometimes two and three years old as of 2022 March.

My Zephyr based application is at this point multi-threaded, and I began by building on a combination of ncs v1.6,1 (Zephyr v2.6.0) sample apps "blinky", "hello_world" and "aws_iot".  In hindsight I now understand that there were multiple threads running before I created additional ones.  These include Zephyr's implementing the main() function in a thread, and the idle thread.  A census of threads is important, and so too that my application has so far used Zephyr's preferred console UART, uart0 and a second UART, uart2 for a separate custom command line interface.  From the above posts I understand that to reach the very lowest power consumption, where the 9160 application processor is fully powered down, I need to set in prj.conf the symbol CONFIG_SERIAL=n.  One post mentions that `mcuboot` and `spm` firmware modules must also be assured to have their prj.conf files disable serial port use and logging.  But I am having trouble locating the prj.conf file for Nordic's ncs/nrf/modules/mcuboot application.  There's no instance of CONFIG_SERIAL in this sub-project or application element of the larger SDK.  Am I correct here that there is not logging and not serial port use in mcuboot?

The other question I have stems from the multiple times I find mention to be sure and disable serial ports in Zephyr apps by setting CONFIG_SERIAL=n.  This is a compile time option.  I find that other parts of current firmware app stop working with this sole change CONFIG_SERIAL=y to CONFIG_SERIAL=n.  This does not make sense to me.  Does this setting turn off a portion of high speed clocks of the ARM Cortex-M33 which are also needed by on chip I2C peripherals?  When configuring no serial in prj.conf, my firmware gives no sign of life and Nordic's Power Profiler II continues to show about 700uA current draw, in spite of code that turns off the LTE modem via at_cmd_write().

In a post I made to CircuitDojo at community.jaredwolff.com the lead engineer there shared a code excerpt which he explained can, assuming driver support, dynamically turn off and on UART devices on a Zephyr supported processor.  This method is also mentioned in Devzone post 81744 from around 2021 December.  Last question I have, not answered by these more recent posts, can a run time UART setting to state PM_DEVICE_STATE_SUSPENDED permit the nRF9160 to draw its ultimately lowest spec'd current of about 1.4uA?

Fair amount of detail here, and I try to keep it short.  Thanks ahead of time for any insight Nordic Team and community can offer to my request for help!

- Ted

  • Hello Didrik,

    Thank you for the further instructions on Kconfig symbol settings for Segger based RTT console.  I'd actually found a number of posts on this very topic last night ( Devzone 75533Devzone 46083Devzone 81416 ).  So far I have tried applying these three config symbols (and a few others from the three posts above, and a Nordic pelion sample app Kconfig file) but am not seeing any messages over RTT.  Here is a command line excerpt which shows invocation of JLinkExe and connection to an ARM Cortex-M33, the application processor in our board's nRF9160 SiP:

    ```ted@localhost:~$ JLinkExe -if SWD
    SEGGER J-Link Commander V7.60g (Compiled Feb 2 2022 10:33:39)
    DLL version V7.60g, compiled Feb 2 2022 10:33:24

    Connecting to J-Link via USB...O.K.
    Firmware: J-Link V11 compiled Dec 9 2021 14:14:49
    Hardware version: V11.00
    S/N: 51018155
    License(s): GDB
    USB speed mode: High speed (480 MBit/s)
    VTref=1.859V


    Type "connect" to establish a target connection, '?' for help
    J-Link>connect
    Please specify device / core. <Default>: CORTEX-M33
    Type '?' for selection dialog
    Device>?
    _IceTransOpen: Unable to Parse address lightdm
    Qt: Session management error: Could not open network socket
    Specify target interface speed [kHz]. <Default>: 4000 kHz
    Speed>

    Device "CORTEX-M33" selected.

    Connecting to target via SWD
    Found SW-DP with ID 0x6BA02477
    DPIDR: 0x6BA02477
    CoreSight SoC-400 or earlier
    Scanning AP map to find all available APs
    AP[7]: Stopped AP scan as end of AP map has been reached
    AP[0]: AHB-AP (IDR: 0x84770001)
    AP[1]: AHB-AP (IDR: 0x24770011)
    AP[2]: JTAG-AP (IDR: 0x12880000)
    AP[3]: APB-AP (IDR: 0x54770002)
    AP[4]: JTAG-AP (IDR: 0x12880000)
    AP[5]: JTAG-AP (IDR: 0x12880000)
    AP[6]: MEM-AP (IDR: 0x128800A1)
    Iterating through AP map to find AHB-AP to use
    AP[0]: Core found
    AP[0]: AHB-AP ROM base: 0xE00FF000
    CPUID register: 0x410FD212. Implementer code: 0x41 (ARM)
    Feature set: Mainline
    Found Cortex-M33 r0p2, Little endian.
    FPUnit: 8 code (BP) slots and 0 literal slots
    Security extension: implemented
    Secure debug: enabled
    CoreSight components:
    ROMTbl[0] @ E00FF000
    [0][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33
    [0][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT
    [0][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB
    [0][3]: E0000000 CID B105900D PID 000BBD21 DEVARCH 47701A01 DEVTYPE 43 ITM
    [0][5]: E0041000 CID B105900D PID 002BBD21 DEVARCH 47724A13 DEVTYPE 13 ETM
    [0][6]: E0042000 CID B105900D PID 000BBD21 DEVARCH 47701A14 DEVTYPE 14 CSS600-CTI
    Cortex-M33 identified.
    J-Link>

    ```

    I've also tried the GUI version `JLinkRTTViewerExe`.  Successful target processor connection there too, but no messages from my application firmware.

    Early on JLinkExe reports a VTref of about 1p8 volts.  Could this voltage be too low to support RTT communications via a JLink Base, hardware version 11.0?

    Are there any other Kconfig symbols I could check in menuconfig?  That is, by invoking `west build -t menuconfig` in my Zephyr app top directory?  Could some other project setting be overriding the three symbols you shared in your latest reply?

    - Ted

  • Are you sure your application is outputting any logs?

    I've attached a slightly modified version of the hello_world sample, which prints using both log and printk, and can be configured to print over both UART and RTT.

    In the current state, it will only print over RTT, but if you comment out/enable the configs that are currently disabling UART, you will get log over UART as well.

    Could you try it, to see if you are able to get RTT log with a known good application?

    2744.hello_world.zip

  • Hello Didrik,

    Thank you for the sample app.  I've just compiled and flashed your shared, modified hello_world app onto our board.  I've invoked `JLinkExe -if SWD` and connected to our ARM Cortex-M33 application processor, as I did in the post a day or two ago.  Same behavior.  I can connect, but I do not see any messages over RTT.  Also no error messages from JLinkExe itself.

    Is there a JLinkExe command I must issue to start the presentation of messages coming across the RTT based physical link?

    JLinkExe has several dozen commands, but none jumps out as a 'start logging / start dispaly' type command.  These commands largely look like commands I would find in the debugger `gdb`.

    - Ted

  • After connecting to the debugger with JLinkExe in one terminal, you can get the log in another terminal by running JLinkRTTClient.

    See the last step (3): https://infocenter.nordicsemi.com/topic/ug_gsg_ses/UG/gsg/connect_rtt_linux.html

Related