Tool/software:
Hi TI Experts,
Customer is working on SDK9.2.
They found that the R5F1_0 log writing to the shared memory could only partially be read out by R5F0_0. Their log only contains of several lines, less than the maximum value 2kBytes in the coding.
After looking into details for the source code of DebugP_shmLogReaderGetString (Log Reader function for R5F0_0), and DebugP_shmLogWriterPutLine (Log Writer function for R5F1_0), customer has two concerns below that may cause this problem.
1: No Lock & Unlock / Resource Mutual Exclusion Mechanism
Like for the application note in Jacinto devices, the theory is the same, other cores writing log to the share memory, and A core read the log out and print. We could see the Lock protection in the coding below.
https://www.ti.com/lit/pdf/spradg5
The appLogWrLock is the function used before other cores writing to the shared memory.
2: Volatile Missing in DebugP_shmLogReaderGetString
We could see that in DebugP_shmLogWriterPutLine, the wr_idx, rd_idx have the protection using volatile shown below.
However, in the DebugP_shmLogReaderGetString, the wr_idx, rd_idx do not have the protection volatile anymore shown below.
We are afraid that the Reader function may read an outdated wr_idx, leading to miscalculation of the buffer's remaining space and consequently skipping newly written logs . Similarly, after the Writer updates wr_idx, the Reader might fail to perceive the latest value, resulting in unread logs.
Could you help check if the above two points are suggested to be modified?
Thanks,
Kevin
