[SOLVED] RTT Output Delayed by Deep Sleep?

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] RTT Output Delayed by Deep Sleep?

    I am working with an Ambiq Apollo3 Cortex M4 processor on a SparkFun Artemis module using Segger Embedded Studio.

    I have a FreeRTOS program that performs a task every 4 seconds. The task takes roughly 100 mSec to run. When FreeRTOS has nothing to do, it puts the processor into a deep sleep mode, so most of the time my system is in deep sleep.

    The periodic task generates a bunch of RTT output as it runs. The odd part is that the last few lines of output get delayed, and don't show up until the task starts running again 4 seconds later. The output is not lost, just delayed. The cycle repeats:the final output from task iteration N always gets delayed until task iteration N+1 starts running.

    I have set a breakpoint at a point where my task has finished generating the RTT output for that iteration, but before FreeRTOS puts the processor to sleep. When the breakpoint hits, the RTT output is still missing. But if I single step one line, the delayed output shows up all at once without needing to wait the 4 seconds until the next iteration.

    I might be wrong about deep sleep being involved, but it sure feels that way. Does Deep Sleep inhibit the RTT output process?
  • In case it wasn't obvious, here is sample output from two iterations.

    Source Code

    1. CAD reports airwaves are clear!
    2. Sending test packet...
    3. TX to addr 0xF8 (seq 13)
    4. rf95: set radio tx!
    5. rf95: set DIOmap!
    6. rf95: set _mode!
    7. TX: wait for send...
    8. TX: sent
    9. TX: wait ACK
    10. TX: ACK!
    11. TX OK! Waiting for response...
    12. rf95: set radio tx!
    13. rf95: set DIOmap!
    14. rf95: set _mode!
    15. RX ok: RSSI = -61
    16. All done in 95920 uSec!
    17. CAD reports airwaves are clear!
    18. Sending test packet...
    19. TX to addr 0xF8 (seq 14)
    20. rf95: set radio tx!
    21. rf95: set DIOmap!
    22. rf95: set _mode!
    23. TX: wait for send...
    24. TX: sent
    25. TX: wait ACK
    26. TX: ACK!
    27. TX OK! Waiting for response...
    Display All
    Lines 1 through 16 should get printed before the system goes to sleep for 4 seconds. Instead, only lines 1 through 11 get printed. Four seconds later, lines 12 through 28 finally get printed out along with the first part of the output from the next task iteration. The next iteration is also missing the last 5 lines of its own output, which come out at the start of the next iteration, and so on.
  • Thanks for the tip, I was able to figure it out.

    Here is what I came up with. First, since the Apollo3 is a Cortex M4, it can detect if a debugger is physically present like this:

    Source Code

    1. // See if a debugger is attached
    2. uint32_t dhcsr = CoreDebug->DHCSR;
    3. bool debuggerAttached = dhcsr & CoreDebug_DHCSR_C_DEBUGEN_Msk;

    Second, in my routine that puts the system to sleep, I always let the system sleep if there is no debugger. If there is a debugger, I only let the system sleep if there is no outbound data in the upbuffer:

    Source Code

    1. // If a debugger is present, we only sleep when all outgoing RTT data is sent
    2. if (!debuggerAttached || !SEGGER_RTT_HasDataUp(0)) {
    3. am_hal_sysctrl_sleep(AM_HAL_SYSCTRL_SLEEP_DEEP);
    4. }
    Now I get all my output at the right time.
  • Hi,
    Glad to see that you found a solution!
    If there are no further questions, I would like to close and archive this thread.
    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.