09202024

Last update2016/05/28 14:38

7.Segger J-LINK でどのようにInfineon devicesをデバッグできますか?

7.Segger J-LINK でどのようにInfineon devicesをデバッグできますか?

The Segger GDB server provided with TrueSTUDIO v3.0.0 does not have support for Infineon devices. This guide describes how to set up a working debug session for Infineon devices by using a beta version of Segger GDB server.

  1. Use the latest Segger GDB server beta, 4.43g (beta) or later.http://www.segger.com/beta-software-version.html
  2. Set debug interface to SWD.
  3. Replace the Initialization script, located at the Startup commands tab in the Debug Configurations dialog, with one of the following scripts:

Script for FLASH:

# Default GDB command file (FLASH) for J-LINK and Infineon XMC4500.

# Flash device

monitor flash device = XMC4500

# Set JTAG speed to 30 kHz

monitor speed 30

# Set GDBServer to little endian

monitor endian little

# Reset the chip to get to a known state.

monitor reset

# Set auto JTAG speed

monitor speed auto

# Setup GDB FOR FASTER DOWNLOADS

set remote memory-write-packet-size 1024

set remote memory-write-packet-size fixed

# Enable flash download

monitor flash download = 1

# Load the program executable

load

# Set a breakpoint at main().

break main

# Run to the breakpoint.

continue

Script for RAM:

# Default GDB command file (RAM) for J-LINK and Infineon XMC4500.

# Flash device

monitor flash device = XMC4500

# Set JTAG speed to 30 kHz

monitor speed 30

# Set GDBServer to little endian

monitor endian little

# Reset the chip to get to a known state.

monitor reset

# Set auto JTAG speed

monitor speed auto

# Setup GDB FOR FASTER DOWNLOADS

set remote memory-write-packet-size 1024

set remote memory-write-packet-size fixed

# Load the program executable

load

# Interrupt vector in RAM

#set *0xe000ed08 = 0x10000000

# Set a breakpoint at main().

break main

# Run to the breakpoint.

continue

NOTE! When debugging in RAM there is problems restarting the debug process. User will have to terminate the debug session and start it again.

6.デバッグ時にどのようにすればラインまで走らせますか?

6.デバッグ時にどのようにすればラインまで走らせますか?

User simply right-clicks on a line of code in the editor window of the the debugger perspective and select Run To line.


As an alternative is is als possible to do this by menu-selection Run -> Run to Line.

5.GDB consoleはどのように開けますか?

5.GDB consoleはどのように開けますか?

Start a debug-session on your target and switch to the Debug perspective.


In the Debug view, select the arm-atollic-aebi-gdb node (not the server node!)


Switch to, or open the Console view.

4.GDBがアサーション失敗によりクラッシュする

4.GDBがアサーション失敗によりクラッシュする

Q: I am receiving this error message on the console when the debug session is started from the TrueSTUDIO® IDE.

"C:/msys/1.0/build/tools/obj/gdb-7.1/gdb/regcache.c:178: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed.A problem internal to GDB has been detected,further debugging may prove unreliable."

A1: Remove all breakpoints from the Breakpoints view before launching your debug session again.

A2: If you have an ST-Link, try erasing the chip using the "STM32 ST-Link Utility" software. The software could be downloaded from here.

  • Make sure the ST-Link and target board are connected to the host PC.
  • Start the "STM32 ST-Link Utility" from Windows start meny.
  • Select "connect" from the "Target" menu.
  • Select "Erase Chip" from the "Target" menu.
  • Restart the debug session from TrueSTUDIO®.

3.異なるbuildとdebugging設定

3.異なるbuildとdebugging設定

Almost all developers start with the Debug configuration for building, downloading and de bugging the behavior of software. There are two important properties of the debug build configuration:

· Complete symbolic information is emitted by the toolchain to help navigate through the information in the high level code during the debug process.

· The lowest level of optimization is normally used.

When code is found to behave as specified, a Release build with no symbolic debug information and high optimization level is usually built. After switching from Debug to Release, the target can be programmed by launching a debugging session. It is important to be cautious when doing so, as unexpected results may occur. The Atollic TrueSTUDIO® philosophy of resolving which executable image to program into the part must be considered carefully in this case.

List making and history keeping are important driving factors in determining the practical behavior of Atollic TrueSTUDIO® development environment.

It is possible to create multiple debug session configurations. This is done by clicking on the down arrow next to the debug icon and selecting debug configurations to bring up the list of existing configurations. By right clicking on an existing configuration, you enable the options to create a new one, duplicate the existing one or delete it. The easiest way to create a new configuration is duplicate an existing one, edit the configuration settings in the dialogue box, and then rename it. You may then toggle among the names of the debug session configurations in the list, if needed to launch the most suitable session for the task at hand.

If the user does not explicitly choose a debug session configuration from an existing list, then Atollic TrueSTUDIO® by default will launch the last debug session configuration that was used. If a developer has been debugging a build created in the Debug build configuration, then switched to the Release build configuration, and launches a debug session by clicking on the debugging icon, Atollic TrueSTUDIO®will fetch the last debugging session configuration, which specifies that the Debug build image is to be programmed into the part. Atollic TrueSTUDIO® has no provision to use a debug session configuration that fetches the image built from the Release configuration and programs that image into the part. This behavior is different from some toolchains that automatically reconfigure their debug launch mechanisms to use the built image from the current build configuration. In TrueSTUDIO®, the user must explicitly create a debug session configuration that uses the build image that is appropriate after switching among build configurations.

For example, the location of the build image built in the Debug configuration for a Project Wizard generated project in the debug session configuration dialogue box is shown here:

The Project Wizard puts Debug and Release folders in the project folder within the workspace. To fetch the image built using the Release configuration, the user may use the Browse button to locate the image, or simply change Debug in the above path to Release and then rename the debug session configuration and switch to it for use.

If desired, other properties of the new debug session configuration can be edited to achieve a desired behavior. For example, setting the temporary breakpoint at the first line of main() could be commented out in the dialogue box under the Startup Debug-tab. In this way it is possible to simply program the part and start execution (load and go) functionality, which is probably the most desirable use case when using a Release build.