Wednesday, October 18th 2017, 2:02am UTC+2

You are not logged in.

  • Login
  • Register

sysopch

Beginner

Date of registration: Oct 12th 2017

Posts: 4

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: 360

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: 4

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: 4

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: 4

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 - 1 time downloaded - Last download: Yesterday, 10:46am)