Tracealyzer in extended memory?

The contents of that trace header indicates that you are using the legacy SNAPSHOT mode (this is no longer developed and will be removed as of next release since it is confusing users). Neither is this mode supported in View afaik.

In trcKernelPortConfig.h it should be
#define TRC_CFG_RECORDER_MODE TRC_RECORDER_MODE_STREAMING

Then use the RingBuffer from streamports folder (set include paths and add trcStreamPort.c).
That will allow you to get snapshot traces from the RingBuffer streamport.

working on it, but I’m not understanding a detail or three.

Apparently, in streaming mode, the following code:


#ifdef _PERCEPIO
	//	 uint8_t  trace_buffer[sizeof(RecorderDataType)] __attribute__((section(".qspi")));
#endif


is not needed because there’s no trace buffer with that format, so that fails. and that means that


//  		 xTraceSetBuffer( (RecorderDataType*) trace_buffer);

doesn’t work either.

which makes me wonder where the program is putting the streaming buffer and how I tell it to put the data in external (to the processor) memory.

I know what it did under snapshot, but I’m missing how streaming buffer is working, unless the streaming buffer simply keeps writing, but, the

#define TRC_CFG_STREAM_PORT_BUFFER_SIZE (16*1000)

still seems to limit the size of the trace. I’m missing something here.

I’ve got a longer post that can be completed once I understand what’s going on and I can figure out how to use extended memory in streaming mode.

I’m getting the larger buffer because I’m moving almost everything out of processor memory to QSPI memory.

Yeah, slower, but I’m still optimizing the system.

Thanks, looking better.

If you want to use the custom buffer (shouldn’t be necessary if you set ATTRIBUTE in trcConfig.h) the function definition is:

traceResult xTraceSetBuffer(TraceRecorderData_t* pxBuffer);
The data type should be TraceRecorderData_t.

Like I said, you shouldn’t need the custom buffer. What size do you get when you #define TRC_CFG_STREAM_PORT_BUFFER_SIZE (16*1000)?

I believe the way to see the size is (for core 0):
RecorderDataPtr→xEventBuffer.xEventBuffer[0]→uiSize

There is approximately 44-48 bytes in overhead per core (depending on arch), so that reduction is expected.

1 Like

A detail - I noted that Trace Filename is ā€œTrace_Dataā€ without any suffix. I think you need to call it something.bin or something.psfs for Tracealyzer/View to identify the trace type correctly.

1 Like

Oddly enough, putting the data in the .qspi section does not work. Putting the data in the .ram2 section (close coupled memory) works just fine.
I think that tracerecorderbuffer setting doesn’t work, but setting the ATTRIBUTE works fine, just not combined with extra variables.

The ā€œsave snapshot traceā€ works properly, When I get this working properly, I’ll write it up, but it will be (of necessity) oriented for the ST-MICRO situation.

I did try importing a general solution, but there wasn’t enough of a structure to tell me what was supposed to be where in the project, and I have to rewrite all the #include statements.

Thanks

You should not need to change any include statements. What do you mean by ā€œgeneral solutionā€? What is unclear? I suspect some kind of misunderstanding or possibly a gap in the documentation, so curious to learn what you are trying to do.

What I meant by general solution was to copy the source code from your website, then include it in the eclipse project by taking the structure as given, then telling eclipse to use this source. This puts your entire structure under the project root.

What you then have to do is go through and remove various directories. IIRC, you cannot have the snapshot general directory in at the same time you have the Jlink directory.

I was further confused by the (apparent) fact that the segger Jlink edu does not support streaming traces, so I did a lot of trying to tweak that solution.

In all of the general source/include files, again IIRC, the include links did not match the structure paths, so all of the source includes (for .h) needed to be adjusted.

What I did do (which works, but with poor documentation-not your fault) was find that ST Micro had ported tracealyzer to the CubeMXIDE ecosystem. That had all the links fixed and included just what was needed.

I’m thinking a bit more of a cookbook approach for you, if you would. What I find many implementers do not do is to give a good idea of just exactly where in the project their code goes.

A bit of the ā€œput it here, the program expects this subdirectory under this project directory, etc.

hope this helps

thanks