Friday, November 24th 2017, 9:13pm UTC+1

You are not logged in.

  • Login
  • Register

sysopch

Beginner

Date of registration: Oct 12th 2017

Posts: 6

1

Thursday, October 12th 2017, 11:22pm

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?

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 363

2

Friday, October 13th 2017, 9:19am

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

sysopch

Beginner

Date of registration: Oct 12th 2017

Posts: 6

3

Monday, October 16th 2017, 3:49pm

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.
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.

Quoted

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

Quoted

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

sysopch

Beginner

Date of registration: Oct 12th 2017

Posts: 6

4

Monday, October 16th 2017, 3:59pm

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

C/C++ Source code

1
SEGGER_SYSVIEW_Conf() 
the first call to

C/C++ Source code

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

C/C++ Source code

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

sysopch

Beginner

Date of registration: Oct 12th 2017

Posts: 6

5

Monday, October 16th 2017, 5:52pm

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.
sysopch has attached the following file:
  • Startup2.7z (7.78 kB - 20 times downloaded - Last download: Nov 22nd 2017, 11:47am)

sysopch

Beginner

Date of registration: Oct 12th 2017

Posts: 6

6

Thursday, October 19th 2017, 10:18am

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

Source code

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


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

SEGGER - Johannes

Super Moderator

Date of registration: Aug 31st 2012

Posts: 363

7

Thursday, October 19th 2017, 3:18pm

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

sysopch

Beginner

Date of registration: Oct 12th 2017

Posts: 6

8

Friday, October 20th 2017, 12:46pm

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