Search code examples
trace32lauterbach

Trace32 CMM script : understanding the Data.Set command

What does the following command mean?

sYmbol.NEW _VectorTable 0x34000000
sYmbol.NEW _ResetVector 0x34000020
sYmbol.NEW _InitialSP   0x34000100
Data.Set EAXI:_VectorTable %Long _InitialSP _ResetVector+1
Solution

  • The command Data.Set writes data values to your target's memory. The syntax of the command is

    Data.Set <address>|<address_range> [<access_width>] {value(s)}

    The <address> to which the data is written to has the form:

    <access_class>:<address_offset>

    A full address, just the address offset and the values (you want to write), can also be represented by debug symbols. These symbols are usually the variables, function names and labels defined in your target application and are declared to the debugger, by loading the target application's ELF file. In this case however the symbols are declared in the debugger manually by the command sYmbol.NEW.

    Anyway: By replacing the symbols with their value in the command Data.Set EAXI:_VectorTable %Long _InitialSP _ResetVector+1 we get the command

    Data.Set EAXI:0x34000000 %Long 0x34000100 0x34000021

    So what does this command actually do?

    • The access-width specifier %Long indicate that 32-bit values should be written. As a result the address will increment automatically by 4 for each specified data value.
    • The value 0x34000100 is written to address EAXI:0x34000000
    • The value 0x34000021 is written to address EAXI:0x34000004
    • The <access_class> "EAXI" indicates that the debugger should access the address 0x34000000 directly via the AXI bus (Advanced eXtensible Interface). By writing directly to the AXI bus, you bypass your target's CPU core (bypassing any MMU, MPU or caches). The leading 'E' of the access class EAXI indicates that the write operation may also performed while the CPU core is running (or considered to be running (e.g. in Prepare mode)). The description of all possible access classes is specific to the target's core-architecture and thus, you can find the description in the debugger's "Target Architecture Manual".

    And what does this exactly mean for your target and the application running on it?

    Well, I don't know you chip or SoC (nor do I know your application). But from the data I see, I guess that you are debugging a chip with an ARM architecture - probably Cortex-M. Your chip's Boot-ROM seems to start at address 0x34000000, while your actual application's start-up code starts at 0x34000020 (maybe with symbol _start).

    For Cortex-M cores you have to program at offset 0 of your vector table (in the boot ROM) the initial value of the stack-pointer, while at offset 4 you have to write the initial value of the program counter. In your case the program counter should be initialized with 0x34000021. Why 0x34000021 and not 0x34000020? Because your start-up code is probably encoded in ARM Thumb. (Cortex-M can only execute Thumb code). By setting the least significant bit of the initial value for the program counters to 1, the core knows, that it should start decoding Thumb instructions. (Not setting the least significant bit to 1 on a Cortex-M will cause an exception).