I've just had a really weird problem with this.
I was never wholly reliable but I found that if I use it in a boot loader, some strange stuff was seen.
AFAICT it is a primitive TX UART which is implemented in the CPU's SWV hardware, and the debugger implements an RX UART. In the Cube debug config you can set up the clock speed, which can be some MHz, so this method of debugging should not hold things up for too long.
/*
* Copied here from core_cm4.h.
\brief ITM Send Character
\details Transmits a character via the ITM channel 0, and
\li Just returns when no debugger is connected that has booked the output.
\li Is blocking when a debugger is connected, but the previous character sent has not been transmitted.
\param [in] ch Character to transmit.
*/
static void ITM_SendChar_2 (uint32_t ch)
{
if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) && /* ITM enabled */
((ITM->TER & 1UL ) != 0UL) ) /* ITM Port #0 enabled */
{
while (ITM->PORT[0U].u32 == 0UL)
{
__NOP();
}
ITM->PORT[0U].u8 = (uint8_t)ch;
}
return;
}
// This sends debug output to the SWV ITM / SWD debug interface
{
ITM_SendChar_2(ch);
return ch;
}
// Function which sends data to the ITM debugger port. Works without needing any stdlib etc code, and
// does not need interrupts. Fast output, megabits/sec.
// Needs CRLF as appropriate.
void debug_puts(char* str)
{
int i=0;
while (str[i]!=0x00)
{
ITM_SendChar_2((uint32_t) str[i]);
i++;
}
}
Can anyone think of why?
I am running with a debugger connected but not necessarily in Debug mode.