[SOLVED] STM32L4 MCU: RTT block not found even with right address specified

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

  • [SOLVED] STM32L4 MCU: RTT block not found even with right address specified

    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 Erwan,

    Thank you for your inquiry.
    Such an issue is not known to us.
    Usually the approach you chose to set the RTT control block location manually should do the trick.
    Could you provide a J-Link log file of the failing session?
    wiki.segger.com/Enable_J-Link_log_file

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
    Files
    • jlink_log

      (174.64 kB, downloaded 638 times, last: )
  • Hello,

    Have you configured SystemView as described in the SystemView Manual and here?
    Did you call traceSTART(); after your board init?


    As a sanitycheck that SystemView is geneally working with your setup could you give the following embOS BSP a try as embOS is instrumented natively by SystemView?

    - download the embOS trial pack here: segger.com/downloads/embos/emb…texM_EmbeddedStudio_Trial

    - install Embedded Studio segger.com/downloads/embedded-studio/

    - unpack the embOS zip

    - navigate to \Start\BoardSupport\ST\STM32L4R5_STM32L4R5ZI_Nucleo and open the .emProject file with Embedded Studio

    - Build project with F7

    - Flash and start debug session with F5

    - Should you end up at a hardfault simply comment out the SystemInit and check if that works
    - Close Embedded Studio

    - Start SystemView


    Do you see a recording now?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
  • Hello Erwan,

    Thank you for the explanation.
    Good to hear that you are up and running again.

    We will close this topic now.
    Happy debugging!

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.