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 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.
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
the first call to uses the configured value, whereas the call to overwrites it with the default 0x10000000. Am I missing something here?

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.

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



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 Joannes,
thanks for the reply.

The call to SEGGER_SYSVIEW_Start() did not help. However, now that you pointed me in the right direction I forced a context switch with taskYIELD() right at the beginning of my SystemInit taks and this seems to do the trick.

Aldo