Dear Yuri
Thank you for getting back to me. I tried your suggestion, but unfortunately without success.
Compared to my previous tests, your suggestion contains an additional check for bit TRCENA in the DEMCR register, so I added this bit to my initialization code and output routine. It finally looks as follows:
void SWO_Enable()
{
const uint32_t _ITMPort = 0;
const uint32_t TargetDiv = 266;
uint32_t StimulusRegs;
DEMCR |= (1 << 24); ITM_LSR = 0xC5ACCE55;
StimulusRegs = ITM_ENA;
StimulusRegs &= ~(1 << _ITMPort);
ITM_ENA = StimulusRegs;
ITM_TCR = 0;
TPIU_SPPR = 0x00000002;
TPIU_ACPR = TargetDiv - 1;
ITM_TPR = 0x00000000;
DWT_CTRL = 0x400003FE;
FFCR = 0x00000100;
ITM_TCR = 0x1000D;
ITM_ENA = StimulusRegs | (1 << _ITMPort);
}
And my output routine is:
int SWO_Write(int iFileHandle, char *pcBuffer, int iLength)
{
int32_t num = 0;
if ((DEMCR & TRCENA) &&
(ITM_TCR & ITM_TCR_ITMENA) &&
(ITM_TER & ITM_TER_PORT0ENA))
{
while (num < iLength)
{
while (ITM_Port32(0) == 0)
{}
ITM_Port8(0) = pcBuffer[num++];
}
return 0;
}
else
{
return (iLength);
}
}
I called SWO_Enable() once, and then SWO_Write() repeatedly, with a delay of 100ms after each character.
By stepping through the code I could prove that the execution path successfully made it through all if-conditions of SWO_Write(), so the actual write
ITM_Port8(0) = pcBuffer[num++];
got executed each time.
On the hardware side, I used an oscilloscope to monitor the behavior
- As expected, the SWDIO/TMS pin (pin 7 of 20) was toggling when the debugger talked to the target while stepping through the code.
- The SWO/TDO pin (pin 13 of 20) stayed high at all times - the i.MX7 did not output any data through this pin.
- To make sure there is no connection issue, I switched the debugger from SWD to JTAG mode without modifying the hardware setup, and started debugging again. Now I was able to see the TDO pin (pin 13 of 20) toggling as expected.
Did you ever see SWO working on the i.MX7, or might that feature be broken at all?
Best Regards,
Andy