Cyclone V Single Stepping not possible

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

    • Cyclone V Single Stepping not possible

      New

      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. **********************************************************************
      6. -------------------------- END-OF-HEADER -----------------------------
      7. File : Altera_Cyclone_V.JLinkScript
      8. Purpose : Script file for Cyclone V series devices
      9. Literature:
      10. [1] J-Link User Guide
      11. Additional information:
      12. For more information about public functions that can be implemented in order to customize J-Link actions, please refer to [1]
      13. */
      14. /*********************************************************************
      15. *
      16. * ConfigTargetSettings
      17. */
      18. int ConfigTargetSettings(void) {
      19. //
      20. // For the Cyclone V device to work with J-Link the Core type needs to be set manually.
      21. //
      22. CPU = CORTEX_A9;
      23. return 0;
      24. }
      25. /*************************** 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.
      11. (gdb) b spl_boot_device
      12. (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
    • New

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

      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.