[SOLVED] SystemView inconsistencies or newbie question?

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

  • [SOLVED] SystemView inconsistencies or newbie question?

    Hi all,


    I am very new to SystemView (but I did use similar tools in the past). I just started to use it on a complex project I am working on (about 15 user tasks) and there are some things I cannot understand.

    The setup is as follows:
    • CPU:Cypress (former Spansion) S6E2CC8J0A, with 32MB external SDRAM
    • RTOS: FreeRTOS 9.0.0
    • FreeRTOS heap: in SRAM section@0x20038000 - I set SEGGER_SYSVIEW_ID_BASE to this address
    • RTT Control Block in data section
    • J-Link SWD connection 8MHz

    Connection issues

    Using the system with a gdb-based debugger (Eclipse with CDT) I am having trouble to start recording events, I frequently get Control Block not found errors
    (especially if I alter data layout with a rebuild). I seem to have found a working startup sequece:
    • set same interface speed in both debugger and systemview
    • make sure to clean all jlink connections (e.g. close debugger and SystemView)
    • load code with debugger
    • run code up to the instruction following SEGGER_SYSVIEW_Conf();
    • open SystemView and start recording
    Is this correct/needed?

    First task never active

    Our system startup is as follows:
    1. hw init up to SEGGER_SYSVIEW_Conf() call
    2. creation of SystemInit task (max prio)
    3. start scheduler
    4. SystemInit task starts executing and starts all the rest of tasks in the system
    This is what I see in SystemView Timeline in the various steps (I start recording after I hit the breakpoint at start of step 2):

    step 2: 4 rows are shown: Unified, Scheduler, Idle and SystemInit - good.

    step 3: I see 2 additional tasks: Task 0x0 (is this the second init task I read about?) and Tmr Svc. Time bars in pale colour appear next to
    SystemInit and "Tmr Svc" tasks. From the docs this indicates the tasks exist.

    step 4: SystemInit task initializes all parts of the system. I see various events corresponding to system calls and Systick ISR. However,
    the SystemInit task's bar colour is always a pale green. Furthermore, Systick's ISR exit events report "Returns to Idle". From the graphical
    representation it looks like SystemInit never executes, while I know it is the one who is performing all activity. When other tasks are created,
    they also get their own bars in pale colours (and this looks correct since they are not running yet - SystemInit is the higher prio task).

    Am I missing something here?



    If I let the system run some second further, I see various task activation bars, sometimes preceded by gray bars indicating the tasks
    are ready but cannot run yet.

    However, I can see a situation like this:
    • system basically IDLE
    • SysTick ISR move 2 tasks into the ready list and returns to IDLE (!)
    • ms elapse, other Systick ISRs occur, some are higher prio tasks are scheduled for a short time
    • after some 60ms the one of 2 tasks above gets executed, the other one gets a gray bar
    Preemption IS enabled in FreeRTOS. What am I missing here?

    Duplicated events?
    In the events list I see multiple System Info and Description lines. The information appears duplicated. Is this expected or suggests a problem?
  • Hi,

    Thanks for the explanation.
    Would it be possible to get a recording of the behavior you described?
    That would allow a better analysis of what might go wrong.

    If you get duplicated or invalid events this indicates that your system is not behaving correctly or that the SystemView data cannot correctly be read.

    Could it be possible that you use low-power modes (call WFI) in your application?
    This would also explain why you cannot connect with SystemView while the system is running.

    Regards
    Johannes
  • Hi Joannes,
    thanks for answering.
    I can't see my post, so I am trying again. Sorry if you get it twice.

    I spent some more time investigating and have some update.

    SEGGER - Johannes wrote:

    Hi,

    Thanks for the explanation.
    Would it be possible to get a recording of the behavior you described?
    That would allow a better analysis of what might go wrong.

    The attached "Startup2" trace show a typical system startup in which you can see the SystemInit task created @8.925us, then the scheduler is started and this task is executed to perform initialization (involving reads from SD which cause ISR #134 to occur) and starts the rest of the tasks @1s.193461us. Anyways the SystemInit task is never shown as active. It looks like all activity is performed in Idle context.
    If you get duplicated or invalid events this indicates that your system is not behaving correctly or that the SystemView data cannot correctly be read.
    If I understood correctly, SystemView periodically asks for System Info, so maybe these are not duplicated events
    Could it be possible that you use low-power modes (call WFI) in your application?
    This would also explain why you cannot connect with SystemView while the system is running.
    We are not (currently) going into low power modes. I guess the connection issues I was having were all triggered by the first connection error. In other words, if I specify the wrong address for the control block (because of a typo or because it moved after a rebuild), after SystemView times out it is not possible to have it connect properly without shutting it off first (and I think I have to reset the debugger connection too).

    Also it is not so clear to me whether I have to use the same interface frequency for the debugger and SystemView's connections (as I would expect, being the same physical interface)
    It is not so easy to keep these frequencies under control: gdbserver is choosing 2kHz even if I ask for 8kHz, but if I manually reselect 8 in JLink Control panel, I get 6kHz.
    SystemView seems to stick with 6.

    I also have some trouble in avoiding overflows in the event stream. I understood 5/6kB of buffer should be enough. Today I am trying to use JTAG and it looks better. Does JTAG allow higher through put than SWD?

    In general, in more complex scenarios, I keep seeing the Idle task scheduled when it should not, and I wonder whether I can trust the tool. For instance, if you check "NoWifiNoEcu" trace @7s.722414 the MathCh task gets ready and is not scheduled for **1 second**, but the system seems kind of Idle. I do know there is a heavy ISR that lasts about 8us every 100us and I am not tracing it to reduce event pressure, but there must be something else which is missing from the picture.

    Thanks
    Aldo
  • I forgot to say that it looks to me that customizing SEGGER_SYSVIEW_ID_BASE is not working properly. In

    C Source Code

    1. SEGGER_SYSVIEW_Conf()
    the first call to

    C Source Code

    1. SEGGER_SYSVIEW_Init()
    uses the configured value, whereas the call to

    C Source Code

    1. SEGGER_SYSVIEW_SetRAMBase(SYSVIEW_RAM_BASE)
    overwrites it with the default 0x10000000. Am I missing something here?
  • sysopch wrote:

    Hi Joannes,
    thanks for answering.
    I can't see my post, so I am trying again. Sorry if you get it twice.

    [...]

    The attached "Startup2" trace show a typical system startup in which you can see the SystemInit task created @8.925us, then the scheduler is started and this task is executed to perform initialization (involving reads from SD which cause ISR #134 to occur) and starts the rest of the tasks @1s.193461us. Anyways the SystemInit task is never shown as active. It looks like all activity is performed in Idle context.

    [...]

    In general, in more complex scenarios, I keep seeing the Idle task scheduled when it should not, and I wonder whether I can trust the tool. For instance, if you check "NoWifiNoEcu" trace @7s.722414 the MathCh task gets ready and is not scheduled for **1 second**, but the system seems kind of Idle. I do know there is a heavy ISR that lasts about 8us every 100us and I am not tracing it to reduce event pressure, but there must be something else which is missing from the picture.


    Oops,
    it looks like I really can't use the forum correctly, sorry. Here is the first of missing attachments.

    The second one is apparently too big. I don't know how to split the trace. I can send it privately or try to get a shorter example in the next days.
    Files
    • Startup2.7z

      (7.78 kB, downloaded 126 times, last: )
  • Hi Joannes,

    to recap, I have a couple of issues which to me appear as real issues with the tool

    1. configuration of SEGGER_SYSVIEW_ID_BASE. I do not think this is working properly out of the box for FreeRTOS. This seems to fix it for me, but I don't know if I am missing any side effect

    Difference-File

    1. --- SEGGER_SYSVIEW_Config_FreeRTOS.c : Working Base,
    2. +++ SEGGER_SYSVIEW_Config_FreeRTOS.c : Working Copy
    3. @@ -105,10 +105,10 @@
    4. *
    5. **********************************************************************
    6. */
    7. void SEGGER_SYSVIEW_Conf(void) {
    8. SEGGER_SYSVIEW_Init(SYSVIEW_TIMESTAMP_FREQ, SYSVIEW_CPU_FREQ,
    9. &SYSVIEW_X_OS_TraceAPI, _cbSendSystemDesc);
    10. - SEGGER_SYSVIEW_SetRAMBase(SYSVIEW_RAM_BASE);
    11. + //SEGGER_SYSVIEW_SetRAMBase(SYSVIEW_RAM_BASE);
    12. }
    13. /*************************** End of file ****************************/
    Display All


    2. Incorrect display of active task in some conditions (see Startup2.7z). I can be sure in this example that the SystemInit task is running and Idle is shown.

    I would appreciate your comments on this, I would like to understand if my configuration is valid.

    Thanks,
    Aldo
  • Hi,

    Regarding ID_BASE it is okay to not call SEGGER_SYSVIEW_SetRAMBase or to call it with 0 as base.

    In your recording the start of the SystemInit task is not recorded.
    Therefore SystemView does not know in which context the system currently executes.
    We might improve this behavior to let the system record its current context on start of recording.

    It might be possible that FreeRTOS does not create a task run event when the scheduler is started,
    but I did not verify this.

    What you can try is call SEGGER_SYSVIEW_Start() immediately after SEGGER_SYSVIEW_Conf()/SEGGER_SYSVIEW_Init().
    This will start recording directly.
    You can then either break after that call and connect with SystemView to catch the full recording, or you run and attach at a later point to get the start and everything from when you attached.

    Regards
    Johannes