This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2634: Is it possible to stall the processor when writing to the STM-500 trace unit

Part Number: AM2634


Tool/software:

Hi,

we want to use the STM500 trace unit to send diagnostic data from the CPU to an external recorder.  With low data volume, wverything else is working as expected.  But when we write data faster than the trace interface can handle, we get overflow messages (MERR) in the trace.

We write the data to a “guaranteed transaction” stimulus address (0x39000118), so we would expect the trace unit to stall the write access instead of sending an overflow message.

According to the feature registers, the STM should support guaranteed transactions.

The ARM STM500 manual mentions a static configuration port “NSGUAREN”, which could be used to disable stalling.  However, I did not find out from the AM263 manual how it is set in this chip.

Can you please help me how to enable stalling, or confirm that stalling is not supported in the AM263

  • Hi Moritz,

    I'm asking one of our debug experts to look into this further but I am not sure we have tested STM-500 trace with AM263 yet.

    Best Regards,

    Ralph Jacobi

  • Moritz,

    STM500 trace has not been tested with AM263. There is a full set of tools for trace debug using Lauterbach hardware: https://www.lauterbach.com/supported-platforms/chips/am2634

    Regards,

    Brennan

  • Hello Brennan,

    I started trace with Lauterbach tools, but that did not change the behaviour: STM trace (+ TPIU output) is working, but stalling is not.

    The STM-500 should support "invariant timing" trace, where it discards messages in case of overload, as well as "guaranteed" trace, where it stalls the writer.  The software on the ECU should be able to select between these modes with bit 7 of the stimulus address.

    We recently used an STM-500 in another MCU, where the selection between invariant timing and guaranteed transfers *did* work.  That unit had the same part ID, architecture, and feature bits as the one in the AM263x.

    Please help me understand, why it does not stall on AM263x -- and how or whether we can make stalling work for our project.  I think the next step should be to find the value of the NSGUAREN flag, which should be readily available at TI.  The NSGUAREN flag (developer.arm.com/.../Non-secure-guaranteed-interface-signals), is available to the integrator, but not to the end user.  When this flag is LOW, guaranteed trace is suppressed.  It would be good to know, how this signal is set, and whether one can change it when running (not sure if  that is possible).  If it is hard tied to low, I think stalling is just not possible.  If it its high, the issue must lie elsewhere.

    I searched for "enables" from the HSM.  But I only found HSM_SEC_MGR_SOC_TRACE_CNTL, which is already set to 0xaaaa, i.e. all four debug enables are already set.