This document serves as a guideline for debugging STM8 MCUs and describes all MCU-specific
TRACE32 settings and features.
Please keep in mind that only the Processor Architecture Manual (the document you are reading at the
moment) is CPU specific, while all other parts of the online help are generic for all CPUs supported by
Lauterbach. So if there are questions related to the CPU, the Processor Architecture Manual should be your
first choice.
Brief Overview of Documents for New Users
Architecture-independent information:
•“Debugger Basics - Training” (training_debugger.pdf): Get familiar with the basic features of a
TRACE32 debugger.
•“T32Start” (app_t32start.pdf): T32Start assists you in starting TRACE32 PowerView instances
for different configurations of the debugger. T32Start is only available for Windows.
•“General Commands” (general_ref_<x>.pdf): Alphabetic list of debug commands.
Architecture-specific information:
•“Processor Architecture Manuals”: These manuals describe commands that are specific for the
processor architecture supported by your debug cable. To access the manual for your processor
architecture, proceed as follows:
-Choose Help menu > Processor Architecture Manual.
•“OS Awareness Manuals” (rtos_<os>.pdf): TRACE32 PowerView can be extended for operating
system-aware debugging. The appropriate OS Awareness manual informs you how to enable the
OS-aware debugging.
Demo and Start-up Script
The on-chip FLASH and the EEProm memory can be programmed via the stm8.cmm script:
1.Select the device prompt B (BDM debugger) and reset TRACE32.
B::
RESet
The device prompt B:: is normally already selected in the TRACE32 command line. If this is not the
case enter B:: to set the correct device prompt. The RESet command is only necessary if you do not
start directly after booting the TRACE32 development tool.
2.Specify the CPU specific settings.
SYStem.CPU STM8S005K6
This command selects the CPU type.
3.Inform the debugger about cashable address range (FLASH/EEPROM)..
MAP.UpdateOnce p:0x8000--0xffff
This is important to speed up the T32 GUI responsiveness. The specified address range will be
accesses only once after a break, thus avoiding unnecessary memory accesses.
4.Reset the target and enter debug mode.
SYStem.Mode Up
This command resets the CPU on the target, enables On-Chip-Debug Mode and issues a breakpoint
right after the reset interrupt routine.The CPU stops executing any instruction, and the user is able to
download the code and test. After this command is executed, it is possible to access memory and
registers.
DO https://manualmachine.com/demo/stm8/flash/stm8.cmm
A typical start sequence of the STM8 is shown below. This sequence can be written to a PRACTICE script
file (*.cmm, ASCII file format) and executed with the command DO<filename>.
B::; Select the ICD device prompt
RESet; Reset the TRACE32 software
MAP.UpdateOnce p:0x8000--
; Specify the address range for caching
0xffff
WinCLEAR; Clear all windows
SYStem.Up; Reset the target and enter debug mode
DO
https://manualmachine.com/demo/stm8/flash/stm8.cmm
; Load the target application into the
Flash
PER.view; Show clearly arranged peripherals
; in window *)
List.Mix; Open source code window *)
Register.view /SpotLight; Open register window *)
Frame.view /Locals /Caller; Open the stack frame with
; local variables *)
Var.Watch %SpotLight flags ast; Open watch window for variables *)
Break.Set 0x1000 /Program; Set software breakpoint to address
; 1000 (address 1000 is within RAM
; address range)
Break.Set 0x101000 /Program; Set on-chip breakpoint
; to address 101000 (address 101000 is
; within Flash address range)
*) These commands open windows on the screen. The window position can be specified with the WinPOS
command.
No special eventInternal error, please consult your
No special eventInternal error, please consult your
No special eventInternal error, please consult your
No special eventCorrupted JTAG connection. Check
The debugger expects to receive a
confirmation for each command sent to
the target. An error occurs in case the
confirmation is not received.
Lauterbach representative.
Lauterbach representative.
Lauterbach representative.
JTAG hardware and settings.
Typically the SYStem.Up command is the first command of a debug session where communication with the
target is required. If you receive error messages like “debug port fail” or “debug port time out” while executing
this command, this may have the reasons below. “target processor in reset” is just a follow-up error
message.
•Open the AREA.view window to display all error messages.
•If the target has no power or the debug cable is not connected to the target, this results in the
error message “target power fail”.
•Did you select the correct core type SYStem.CPU<type>?
•There is an issue with the SWD interface. Maybe there is the need to set jumpers on the target to
connect the correct signals to the SWD connector.
•The target is in an unrecoverable state. Re-power your target and try again.
•The core is kept in reset.
•There is a watchdog which needs to be deactivated.
The debugger is accessed via Internet/VPN and the performance is very
slow. What can be done to improve debug performance?
The main cause for bad debug performance via Internet or VPN are low data
throughput and high latency. The ways to improve performance by the debugger
are limited:
In PRACTICE scripts, use "SCREEN.OFF" at the beginning of the script
and "SCREEN.ON" at the end. "SCREEN.OFF" will turn off screen
updates. Please note that if your program stops (e.g. on error) without executing "SCREEN.OFF", some windows will not be updated.
"SYStem.POLLING SLOW" will set a lower frequency for target state
checks (e.g. power, reset, jtag state). It will take longer for the debugger to
recognize that the core stopped on a breakpoint.
"SETUP.URATE 1.s" will set the default update frequency of
Data.List/Data.dump/Variable windows to 1 second (the slowest possible
setting).
prevent unneeded memory accesses using "MAP.UPDATEONCE
[address-range]" for RAM and "MAP.CONST [address--range]" for
ROM/FLASH. Address ranged with "MAP.UPDATEONCE" will read the
specified address range only once after the core stopped at a breakpoint or
manual break. "MAP.CONST" will read the specified address range only
once per SYStem.Mode command (e.g. SYStem.Up).
What can be the reasons why setting a software breakpoint fails?
Setting a software breakpoint can fail when the target HW is not able to
implement the wanted breakpoint.
Possible reasons:
The wanted breakpoint needs special features that are only possible to
realize by the trigger unit inside the controller.
Example: Read, write and access (Read/Write) breakpoints ("type" in Break.Set
window). Breakpoints with checking in real-time for data-values ("Data").
Breakpoints with special features ("action") like TriggerTrace, TraceEnable,
TraceOn/TraceOFF.
TRACE32 can not change the memory.
Example: ROM and Flash when no preparation with FLASH.Create,
FLASH.TARGET and FLASH.AUTO was made. All type of memory if the
memory device is missing the necessary control signals like WriteEnable or
settings of registers and SpecialFunctionRegisters (SFR).
Contrary settings in TRACE32.
Like: MAP.BOnchip for this memory range. Break.SELect.<breakpoint-type>
Onchip (HARD is only available for ICE and FIRE).
RTOS and MMU:
If the memory can be changed by Data.Set but the breakpoint doesn't work it
might be a problem of using an MMU on target when setting the breakpoint to a
symbolic address that is different than the writable and intended memory
location.
In order to perform a memory read or write while the CPU is executing a
program, the debugger stops the program execution shortly. Each short
stop takes 1 … 100 ms depending on the speed of the debug interface
and on the number of the read/write accesses required.
A red S in the state line of the TRACE32 screen indicates this intrusive
behavior of the debugger.
DeniedDo not allow intrusive run-time memory access.
NonstopLock all features of the debugger that affect the run-time behavior.
Nonstop reduces the functionality of the debugger to:
•Run-time access to memory and variables
•Trace display
The debugger inhibits the following:
•To stop the program execution
•All features of the debugger that are intrusive (e.g. action Spot for
breakpoints, performance analysis via StopAndGo mode, conditional breakpoints etc.)
DeniedReal-time memory access during program execution to target is disabled.
SYStem.Mode Establish the communication with the target
Format:SYStem.Mode <mode>
<mode>:Down
Go
Up
Default: Down.
DownDisables the debugger. The state of the CPU remains unchanged.
GoResets the target and starts execution.
UpResets the target and stops the CPU at the reset vector.
SYStem.LOCK Lock and tristate the debug port
Format:SYStem.LOCK [ON | OFF]
Default: OFF
If the system is locked, no access to the debug port will be performed by the debugger. While locked, the
debug connector of the debugger is tristated. The main intention of the SYStem.Lock command is to give
debug access to another tool.
SYStem.Option IMASKASM Disable interrupts while single stepping
Format:SYStem.Option IMASKASM [ON | OFF]
Default: OFF.
If enabled, the interrupt enable flag of the EFLAGS register will be cleared
operations. After the single step, the interrupt enable flag is restored to the value it had before the step. It is
turned on to make sure that no interrupt routine is serviced between break and go states.
during assembler single-step
SYStem.Option IMASKHLLDisable interrupts while HLL single stepping
Format:SYStem.Option IMASKHLL [ON | OFF]
Default: OFF.
If enabled, the interrupt enable flag of the EFLAGS register will be cleared
operations. After the single step, the interrupt enable flag is restored to the value it had before the step.
TrOnchip.VarCONVert Adjust complex breakpoint in on-chip resource
Format:TrOnchip.VarCONVert [ON | OFF]
The on-chip breakpoints can only cover specific ranges. If you want to set a marker or breakpoint to a
complex variable, the on-chip break resources of the CPU may be not powerful enough to cover the whole
structure. If the option TrOnchip.VarCONVert is set to ON, the breakpoint will automatically be converted
into a single address breakpoint. This is the default setting. Otherwise an error message is generated.
The Microchip STM8 architecture does not support software breakpoints.
On-chip breakpoints for instructions
The STM8 MCUs support a total of two on-chip breakpoint registers which can be used as program
breakpoints to stop and debug the program which executes always in the Flash.
On-chip breakpoints for data
Data breakpoints are used to analyze the read and write accesses to global variables. The data breakpoints
can be triggered with respect to the data address or access type, i.e. read, write or both, or the data value.
The two instruction breakpoints of STM8 MCUs can be used as data breakpoints
In case of an on-chip data breakpoint, every load and store instruction is checked with respect to the
breakpoint address, access type and the value. The data breakpoints are especially useful to find out when
a global variable is written with a certain value. It is not possible to implement a similar breakpoint in software
without affecting the real-time behavior of the system. Since the load and store instructions work on RAM,
data breakpoints always point to addresses on RAM.