Hello,


Our company is using SystemView to enable runtime thread scheduling analysis on various boards.
We are trying to enable SystemView with the MCU STM32L4S5VI on a custom board and we have some issues.


Here is the target configuration:
- MCU = STM32L4S5VI
- FreeRTOS version = V10.2.1
- SEGGER J-Link ARM V9.30
- SystemView version 2.52a and 3.30 (to see if it works on one of them at least)
- FreeRTOS patch to enable SystemView applied:
[SOLVED] SystemView Kernelpatch for FreeRTOS 10.2.0?
- _SEGGER_RTT address: 0x20007058


Main problem: RTT Control Block not found.
------------------------------------------


With other boards, to solve this error, I switch from auto-detection to Search Range with the right _SEGGER_RTT address and it works.
However, it is not the case with the STM32L4 even if the RTT block address is right. Indeed, the address has been verified in Debug mode.
Since the address is below the address 0x2002000, it is within the SRAM1 bank. Nevertheless, SystemView or J-link seem not able to retrieve
RTT data.


Here is the SystemView Target configuration used:
- Connection to J-Link: USB
- Target device: STM32L4S5VI
- Target interface & Speed: SWD 4000 kHz
- RTT Control Bloc Detection: 0x20007058 0x1000


Hence, my questions are:


- Do you know what could prevent SystemView to detect the RTT block address with the right address mentionned?
- Are there some specific rules about this MCU?




Deeper investigation: RTT communication
---------------------------------------


In order to go deeper in the first problem issue, I created a FreeRTOS task which uses every one second:
SEGGER_RTT_WriteString(0, "Hello World!\n\r");
Then, I should be able to see this print if the RTT communication works at least. I used the software J-Link RTT viewer V7.00a in order to see
this output. However I could not see anything in the Terminal 0 and All Terminals displays.


When I want to see channel information I got the pop up window:
"RTT channel information is not available, if "Existing session" is used to connect to the target."


What is strange is that J-link seems to detect correctly the MCU.
Finally, here is the log output from J-Link RTT viewer V7.00a:


LOG: J-Link RTT Viewer V7.00a: Logging started.
LOG: Connecting to J-Link via USB...
LOG: Device "STM32L4S5VI" selected.
LOG: Found SW-DP with ID 0x2BA01477
LOG: Found SW-DP with ID 0x2BA01477
LOG: DPIDR: 0x2BA01477
LOG: Scanning AP map to find all available APs
LOG: AP[1]: Stopped AP scan as end of AP map has been reached
LOG: AP[0]: AHB-AP (IDR: 0x24770011)
LOG: Iterating through AP map to find AHB-AP to use
LOG: AP[0]: Core found
LOG: AP[0]: AHB-AP ROM base: 0xE00FF000
LOG: CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
LOG: Found Cortex-M4 r0p1, Little endian.
LOG: FPUnit: 6 code (BP) slots and 2 literal slots
LOG: CoreSight components:
LOG: ROMTbl[0] @ E00FF000
LOG: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
LOG: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
LOG: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
LOG: ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
LOG: ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
LOG: ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
LOG: RTT Viewer connected.


Nevertheless, the RTT communication may be the issue. Then my questions are:


- Do you know how to solve this RTT communication issue?
- Did you encounter this kind of issue with STM32L4 series?


I hope I give you enough information to help me to solve this issue.
Thanks in advance for your feedbacks.


Best regards,
ErwanM

Hello Nino,

Thanks for your answer.

I got some news since my first message:
- The j-link connection is good. I'm able to use J-link commander and read data in the memory of the MCU.
- At the beginning of the RTT block in RAM (currently it is 0x20007040 with a simplified code) we have the ASCII characters for "SEGGER" to help SystemView to find the block
- Then, RTT block is found finally bvy SystemView, after an additional build & flash on the board.


Now the issue is that no traces are displayed. We have the warning message in SystemView software:
"Warning: Did not record SystemView TRACE START event, yet"


You can find attached to this message the log of the last try to connect SystemView with the board.
The log file has been enabled by J-link commander command log.
As you can see in the beginning of the log file, there is a first j-link mem32 command I did before to start SystemView.

I hope these logs will help you to understand the issue.
I keep you informed of our progress in our side.

Best regards,
Erwan

Hello Nino,


Thanks for your reply.


Yes I followed instructions in the User Manual and the FreeRTOS specific notice.
I only use SEGGER_SYSVIEW_Conf(); since the manual says that connect SystemView to the MCU starts trace writing.


As a sanity check and to be in a configuration closer to the project studied, I managed to run SystemView on the prototype board with a CubeIDE project.
It is configured with the minimum to work with STM32L4 and FreeRTOS 10.2.1.


In fact, our main issue in the project studied was that we could not at first to Debug (need ST-Link dongle) in the same time as using SystemView (J-link probe). Then, we managed to enable Debug through J-link with J-link commander mainly and it apperead that the program blocks the code execution each time a semi-hosting trace instruction is used out of a Debug session with a breakpoint command directly in the code. Hence, trace could not be generated since the CPU was halted.


Once every trace call are removed, the CPU runs properly and SystemView traces as well.


Thus, the problem is solved you may close this topic.


Thanks again for the help.

Best regards,
Erwan