@@ -123,3 +123,21 @@ Once the test has started (and an additional delay of 10 seconds has elapsed), y
...
@@ -123,3 +123,21 @@ Once the test has started (and an additional delay of 10 seconds has elapsed), y
The exact settings and steps necessary to connect to a remote GDB server depends on the IDE you are using.
The exact settings and steps necessary to connect to a remote GDB server depends on the IDE you are using.
The SWO output (SWV feature) is available on port 2332.
The SWO output (SWV feature) is available on port 2332.
<br/>
## How to use the data trace service to detect a stack overflow
The data trace service is typically used to keep track of a the value of a variable. However, it can also be used to monitor larger memory areas for unwanted accesses, for example to detect a stack overflow. For this to work, you first need to determine how large the heap is (statically allocated memory in SRAM, the `.bss` + `.data` sections). Let's assume the heap is less than 12kB in size and the SRAM starts at address `0x20000000`. If the program works as intended, there should never be a memory access to an address right after the heap (e.g. `0x20003000`). Only if something goes wrong (e.g. the stack grows too large), this memory location will be access / written to. In this example, we could configure the data trace service as follows:
```
<debugConf>
<obsIds>1</obsIds>
<cpuSpeed>48000000</cpuSpeed>
<dataTraceConf>
<variable>0x20003000</variable>
<mode>W</mode>
<size>16</size>
</dataTraceConf>
</debugConf>
```
The data trace service will then watch the memory region from `0x20003000` to `0x20003010` and report any write access to this area. Note that we could also monitor a larger area. However, the tracing address (`variable`) must always be aligned to the size. If for example the heap ends at `0x20003001` and you want to monitor an area of 256 bytes, you will have to round up the address to `0x20003100` in order to be aligned to 256 bytes.