LPC824 MTB (Micro Trace Buffer) in standalone mode

[lpcware]

Content originally posted in LPCWare by mariusz.mpicosys on Tue Apr 19 22:44:27 MST 2016
Hello,

I'm trying to use MTB on LPC824 in standalone mode.
The idea is to activate MTB on power up and then output the buffer
using UART when some unexpected event happens like hard fault.
The initialization looks like this:

#if !defined (__MTB_DISABLE)
    Chip_Clock_EnablePeriphClock(SYSCTL_CLOCK_MTB);
    LPC_MTB->MASTER = 0x00000000UL;
    LPC_MTB->POSITION = 0x00000000UL;
    LPC_MTB->FLOW = 0x00000000UL;
    // __MTB_BUFFER_SIZE == 256
    LPC_MTB->MASTER = MTB_MASTER_EN | (8UL - 4UL);
    LPC_SYSCON->EXTTRACECMD = (1 << 0)
#endif

All seems okay. I can see the POSITION register increment and some values
written at addresses 0x10000000-0x100000FF. The problem is that there are gaps
in the branching history. Running the code in debug mode or just attaching via SWD
fixes the situation until next power off.

Is this expected behavior?
How can fix this problem without attaching a programmer via SWD?

Thanks,
Mariusz

[lpcware]

bump

[lpcware]

Content originally posted in LPCWare by mariusz.mpicosys on Thu Apr 21 15:22:08 MST 2016
Hello,

Thanks for the confirmation. This is somewhat inconvenient. On some boards the SWD pins are not available (their function changed) and MTB is very useful in investigating unexpected software behavior. The CoreSight MTB document describes four signals - DBGEN, NIDEN, HSELSFR and HSELRAM - that potentially could influence the MTB block activation/functioning. Specially the two last ones:

---

Quote:

The memory regions are selected by the
HSELSFR and HSELRAM inputs respectively. Only one of these select inputs can be HIGH
at a time. If they are both HIGH at the same time the behavior is UNPREDICTABLE.

---

Enabling proper MTB activation from software would be very nice feature.
Help regarding this topic is greatly appreciated.

Thanks,
Mariusz

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Apr 21 09:54:07 MST 2016
Hi Mariusz,

I'm afraid that this is expected behavior. The MTB is designed to be used in debug mode. When running standalone the SRAM clocking is optimized to be turned off where there is no activity detected to save power. MTB activity is not included in this consideration, therefore you get dropped packets when the MTB tries to write to unclocked SRAM.

By entering debug mode by attaching or running in debug this power optimization is disabled and so no packets get dropped.

Unfortunately you can't enable debug mode from software, it can only be enabled via the Debug Access Port (eg the SWD connection).

I will try and find out is there is any other way to prevent the SRAM from getting unclocked (although this will increase the power usage).

Ciao,

LPCXpresso Support.

[lpcware]

Content originally posted in LPCWare by mariusz.mpicosys on Wed Apr 20 21:57:07 MST 2016
Yes, I'm sure that the buffer has proper size and it's not used by anything else. As I wrote, the problem does not occur after an SWD attach. It also looks like the values that are wrong, are the values from a previous sweep i.e. they are valid addresses that match the program execution order.

[lpcware]

Content originally posted in LPCWare by vtw.433e on Wed Apr 20 10:15:23 MST 2016
Have you reserved 256 words for the trace buffer? i.e. it is not used by anything else, so avoids the possibility of it being overwritten.