Trice v0.54.1 -> v0.55.1 : TriceDepthMax idle value

[CMLoureiro]

Hi Thomas,

On my application I recently updated the trice version from v0.54.1 to 0.55.1 and I noticed that idle trace depth ( (only trace RTOS thread running) increased from 84 to 2680 bytes.

Test scenario:

• trace line: TRICE16( Id(7500),"TRACE: TriceDepthMax =%4u\n", TriceDepthMax() );
• trace is generated every 500ms
• TriceTransfer() is called every 20ms

Host output:

v0.54.1
Dec 22 10:31:27.718998 /dev/ttyACM0: trace.c: 131 3627998749 TRACE: TriceDepthMax = 84
Dec 22 10:31:28.216879 /dev/ttyACM0: trace.c: 131 3628498749 TRACE: TriceDepthMax = 84
Dec 22 10:31:28.714813 /dev/ttyACM0: trace.c: 131 3628998749 TRACE: TriceDepthMax = 84

v0.55.1
Dec 22 11:07:09.648332 /dev/ttyACM0: trace.c: 131 28353 TRACE: TriceDepthMax =2680
Dec 22 11:07:10.145972 /dev/ttyACM0: trace.c: 131 4065 TRACE: TriceDepthMax =2680
Dec 22 11:07:10.643757 /dev/ttyACM0: trace.c: 131 45313 TRACE: TriceDepthMax =2680

Could it be from my configuration(attached) ?

Thank you
triceConfig.h.txt

[rokath]

The TriceDepthMax measures the max used trice buffer depth. Could it be, you have a lot of trice messages at system start before starting to transmit them? Maybe you disable all not needed trice messages to just the triceDepthMax message, trying to track the error? Hopefully I find time in the next days to have a closer look. Your triceConfig.h looks good. The only question I have is triceTxDataRegisterEmpty(). This function is usually needed to transmit the next byte.

[rokath]

Your TRICE_HALF_BUFFER_SIZE 8000 value is real big. The #define TRICE_DATA_OFFSET (((TRICE_HALF_BUFFER_SIZE/3)+4)&~3) value is part of the used depth and 8000/3=2666 -> that is what you measure. Because the half buffer is re-used during TCOBS encoding we need some reserved space at the half buffer start. A few bytes, like 100, should be enough usually. In worst case the buffer gets filled to the end only with 4-byte trices and each gets an additional sigil and a 0, so 33% are safe. is the appropriate comment. I did not check, but in v54.1 this dynamic computation was probably not yet implemented and maybe only 80 bytes statically assigned.

[CMLoureiro]

Hi Thomas,

Happy New Year for you!
And sorry for the late reply... I have been on holidays.

Thank you very much for the clarification.
Regards