[ABANDONED] Cyclone V Single Stepping not possible

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

  • [ABANDONED] Cyclone V Single Stepping not possible

    Hello,

    I am trying to debug U-Boot SPL on a Cyclone V Soc. I have a J-Link Ultra + that is connected via JTAG to the Cyclone V.
    My Operating System is Ubuntu 20.04 LTS running in a Virtual Box.

    The JLink FW Version is:
    Firmware: J-Link Ultra V5 compiled Jun 29 2021 16:14:06
    Hardware: V5.00

    So far I have managed to connect to the Device with the command:

    Source Code

    1. JLinkGDBServer -if JTAG -device "CYCLONE V" -speed 4000 -JTAGConf -1,-1 -AutoConnect 1 -JLinkScriptFile Altera_Cyclone_V.JLinkScript



    The JLink Script File is necessary to enable the monitor reset command in gdb. It contains:



    Brainfuck Source Code

    1. /*********************************************************************
    2. * (c) SEGGER Microcontroller GmbH & Co. KG *
    3. * The Embedded Experts *
    4. * www.segger.com *
    5. **********************************************************************
    7. -------------------------- END-OF-HEADER -----------------------------
    9. File : Altera_Cyclone_V.JLinkScript
    10. Purpose : Script file for Cyclone V series devices
    11. Literature:
    12. [1] J-Link User Guide
    14. Additional information:
    15. For more information about public functions that can be implemented in order to customize J-Link actions, please refer to [1]
    16. */
    18. /*********************************************************************
    19. *
    20. * ConfigTargetSettings
    21. */
    22. int ConfigTargetSettings(void) {
    23. //
    24. // For the Cyclone V device to work with J-Link the Core type needs to be set manually.
    25. //
    26. CPU = CORTEX_A9;
    27. return 0;
    28. }
    30. /*************************** end of file ****************************/
    Display All
    I can now connect to the Target form within gdb-multiarch load U-Boot SPL and start execution:

    Source Code

    1. (gdb) target remote localhost:2331
    2. (gdb) file u-boot-spl
    3. (gdb) monitor reset
    4. (gdb) load
    5. Loading section .text, size 0xa448 lma 0xffff0000
    6. Loading section .rodata, size 0x25f8 lma 0xffffa448
    7. Loading section .data, size 0x54 lma 0xffffca40
    8. Loading section .u_boot_list, size 0x70c lma 0xffffca94
    9. Start address 0xffff0000, load size 53664
    10. Transfer rate: 221 KB/sec, 8944 bytes/write.
    12. (gdb) b spl_boot_device
    13. (gdb) cont
    Display All
    As requested gdb halts @ spl_boot_device:


    Source Code

    1. reakpoint 1, spl_boot_device () at arch/arm/mach-socfpga/spl_gen5.c:32
    2. 32 const u32 bsel = readl(&sysmgr_regs->bootinfo);
    3. (gdb) n
    When I try to single step now, gdb hangs and I get an endless loop in the JLinkGDBServer Output:


    Source Code

    1. Setting breakpoint @ address 0xFFFF173A, Size = 2, BPHandle = 0x0056
    2. Starting target CPU...
    3. ...Breakpoint reached @ address 0xFFFF173A
    4. Reading all registers
    5. Removing breakpoint @ address 0xFFFF173A, Size = 2
    6. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    7. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    8. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    9. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    10. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    11. Read 4 bytes @ address 0xFFFF173A (Data = 0xBD106020)
    12. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    13. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    14. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    15. Setting breakpoint @ address 0xFFFF173A, Size = 2, BPHandle = 0x0057
    16. Starting target CPU...
    17. ...Breakpoint reached @ address 0xFFFF173A
    18. Reading all registers
    19. Removing breakpoint @ address 0xFFFF173A, Size = 2
    20. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    21. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    22. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    23. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    24. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    25. Read 4 bytes @ address 0xFFFF173A (Data = 0xBD106020)
    26. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    27. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    28. Read 2 bytes @ address 0xFFFF173A (Data = 0x6020)
    29. Setting breakpoint @ address 0xFFFF173A, Size = 2, BPHandle = 0x0058
    30. Starting target CPU...
    Display All
    What am I missing?


    Best regards,

    Martin

  • Hi,

    Some hint for the beginning:
    You may throw away the J-Link script file. By selecting "Cyclone V" as the MCU to be debugged,
    J-Link already knows that it is Cortex-A9 based.
    So the script you are passing, does not provide any additional information.

    To the problem itself:
    I am not sure if J-Link GDB Server is to blame here.
    Even though the log you provided does not show the session from the beginning, it looks like GDB itself ends up in some endless loop.
    • "n" tells GDB to go to the next C-code line.
    • GDB seems to calculate that this line starts at 0xFFFF173A
    • GDB sets a breakpoint at that address
    • GDB starts the CPU core and waits for it to hit the breakpoint
    • The BP is hit and GDBServer reports the halt reason to GDB
    • GDB seems to end up in some kind of endless loop because it now sets a BP to the same address and let the CPU run again
    So far, this looks GDB driven to me. GDBServer is only doing what it is told to do.

    Questions:
    1) Has the ELF file be generated with GCC from the same version of the toolchain that you use GDB from?
    2) Did you give Ozone a try? Does it work better here? segger.com/products/development-tools/ozone-j-link-debugger/
    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.

  • Hi Alex,

    thank you for your reply.

    I have now used the gdb from the toolchain that was used to create the SPL bootloader and have the same result.
    I end up in an endless loop.
    When I load the u-boot-spl file in Ozone, it appears that Ozone can not read the symbols correctly from the elf File,
    even though the Linux file command claims that it is an .elf file:

    Source Code

    1. cdev@linuxvm:~/tmp/uboot-rel_socfpga_v2019.04_20.01.02_pr/spl$ file u-boot-spl
    2. u-boot-spl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

    Anyhow, when I specify the offset 0xFFFF0000 (On Chip RAM from which SPL is executed) I can sucessfully load the
    program and run it. But as there are no symbols found, debugging is difficult.

    I could try to create a minimal program, to see, if debugging is possible with that.