miltriada.blogg.se - Segger embedded studio trouble linking

Segger embedded studio trouble linking how to#
Segger embedded studio trouble linking code#
Segger embedded studio trouble linking Bluetooth#

To debug using ST-Link GDB Server, open the project options and set: ST-Link GDB Server Embedded Studio project settings If another port should be used, change the project option as well as the command line option -port. The default connection is "localhost" on port 2331. The default GDB Server Command Line is "$(JLinkDIR)/JLinkGDBServerCL" -device "$(DeviceName)" -silent.

The GDB Server Command Line is used to start J-Link GDB Server.įor the installation path the macro $(JLinkDir) can be used.Īdditionally at least the device name need to be set and if necessary the target connection needs to be configured via command line optoions.

Debug -> GDB Server -> Type to "J-Link".

Debug -> Debugger -> Target Connection to "GDB Server".

To debug using J-Link GDB Server, open the project options and set: Note: It is recommended to use the native J-Link Support instead of the J-Link GDB Server.

Segger embedded studio trouble linking how to#

2.2 How to start the ST-Link GDB Server.

For limitations to what can be done in the different functions of the custom monitor part, please refer to the J-Link User Guide. The monitor modules simply need to be compiled, linked and downloaded with the application.

JLINK_MONITOR_OnPoll(): Called periodically while the CPU is in debug mode.

Target application is already stopped at this point.

JLINK_MONITOR_OnEnter(): Called once just before entering the monitor.

JLINK_MONITOR_OnExit(): Called once just before leaving the monitor and restarting the target application.

The custom monitor part provides the following functions where the user can add functionality/maintenance which needs to be done in debug mode: SEGGER delivers a template for this part.

A custom monitor part providing some functions that can be filled in by the user.

This part is delivered by SEGGER and should not be modified by the user.

A generic monitor that handles communication with J-Link.

Segger embedded studio trouble linking code#

The monitor code consists of the following parts: So technically, the CPU is still running and executing code while the application itself is halted, allowing it to still handle some interrupts as well as some synchronous maintenance operation that can be done within the monitor code. In contrast to halt mode debugging, in monitor mode debugging the target CPU does not halt on a debug request but takes a debug interrupt instead and jumps to a specific debug interrupt handler which then handles the communication with J-Link and also some low-level application maintenance that may be needed to be done while the application is halted. Monitor mode debugging allows the developer to debug in this scenario, too. to become totally unresponsive, so packets cannot be received anymore, even keep-alive packets etc.

Target application has an ethernet part where halting the CPU would cause the IP stack etc.

Segger embedded studio trouble linking Bluetooth#

Monitor mode debugging allows the Bluetooth "keep-alive" interrupt(s) to run and handle the low-level Blutetooth communication while the rest of the application is halted and can be debugged.

Target application has a Bluetooth part where halting the complete target application would cause the Bluetooth communication to break down.

Monitor mode debugging allows the PWM part of the application to keep running while the rest of the application is halted and can be debugged.

Target application has a motor control part which makes use of Pulse-width modulation (PWM), and the PWM units also stop when the CPU is halted, possibly leaving the PWM unit and motor control in an undefined or even dangerous state.

There are several use-cases where monitor mode is the only convenient way to debug an application: