[Linux-stm32] [RFC] Add trig_ts function in STM to generate TRIG_TS packet periodically

[Mike Leach]

Hi,

On Thu, 23 Feb 2023 at 06:41, Jinlong Mao <quic_jinlmao at quicinc.com> wrote:
>
>
> On 2/22/2023 8:19 PM, Mike Leach wrote:
> > Hi
> >
> > A couple additional points...
> >
> > On Wed, 22 Feb 2023 at 11:00, Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
> >> On 21/02/2023 06:53, Jinlong Mao wrote:
> >>> Hi all,
> >>>
> >>> When there is some small packet sent from STM to ETR, the small packet
> >>> could be stuck between source
> >>> and sink even if manual flush is set when disable ETR.
> >> Why ? The manual flush should trigger a flush request upstream
> >> and eventually cause a flush ? If this doesn't work as expected
> >> we should try to get to the bottom of that first, before jumping
> >> into "software work arounds".
> >>
> >>> So there is requirement that flush the STM trace periodically after
> >>> enabling STM to ETR.
> >>>
> >>> STM can generate TRIG_TS packet by writing to offset 0xF0 of the driver
> >>> STM stimulus port.
> >>> ETR has ability to initiate a flush on seeing a TRIG_TS packet.
> >> Why is this different from the "manual flush" and how does it help ?
> >> Is it because one of the components doesn't respond properly to the
> >> flush request ?
> >>
> >>
> >> Kind regards
> >> Suzuki
> >>
> >>> For this requirement, I want to create a sysfs node like trig_ts for STM.
> >>> When writing 1 to this sysfs node, a timer with 1 second periodicity in
> >>> STM will start to generate the trig_ts packet to ETR.
> > If this is really needed, then the source writing the data you wish to
> > flush should write to the relevant STM stimulus port. There is no
> > justification for a polling mechanism when the client itself can do
> > the write at a  time you believe it to be needed.
> >
> >>> Once ETR receive the TRIG_TS packet, it will initiate a flush.
> > The ETR does not interpret STM packets - this alone will not initiate a flush.
> >
> > It is possible to program the ETR to respond to the FLUSHIN or TRIGIN
> > signals via the ECT/CTI network of signals, or a trigger event in the
> > trace stream (ATID=0x7D) if a source (in this case the STM) is
> > programmed to output these specific packets when it generates trigger
> > packets in its own protocol.
> > Programming bits in the FFCR control these operations, STM must be
> > programmed separately to generate appropriate output responses on
> > trigger packets.
> >
> > Regards
> >
> > Mike
>
> Hi Suzuki & Mike,
>
> There is USB case support in our internal device.
> Data path is that  STM data ---> ETR -----> USB ----> PC tool.
>
> On PC tool, it can show the logs from ETR in real time.
>
> When one small packet send from STM to ETR, it can be stuck between STM
> and ETR.
> When the packet stuck happens, it will be flushed to ETR only when some
> other packets
> generated from STM source or CTI flush commands are sent. If the time is
> too long to wait
> for next packets coming, user will consider that issue happens with
> previous small packet.
> And user's requirement is that packet from STM can be flushed to ETR
> automatically instead
> of sending commands manually.
>
> Is it appropriate to add a sysfs node for STM to generate the trigger
> packet periodically for such case ?
>

It is likely that the small amount of data is not sufficient to fill a
16byte packet in the ETR formatter, therefore is not being output.
Therefore when you do add more data, or initiate a flush then this
data will then be output - possibly with padding to complete the
formatter frame.

As mentioned before, it should be sufficient to program the ETR to
flush on trig in, the STM to emit a trigger packet into the ATB stream
when protocol packets such as TRIG_TS is written, and use the STM
client that is writing the data to write to the TRIG_TS offset when
data needs flushing. This is no different than flushing any standard
iostream.

A periodic write should not be needed.

Regards

Mike


>
> Thanks
> Jinlong Mao
>
>
> >
> >>> Could you please help to provide your comments on this requirement ?
> >>>
> >>> Thanks
> >>> Jinlong Mao
> >>>
> >


--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK