[SOLVED] NXP RT1020: Corrupted SWO printf output [MCUXpresso, J-Link] - Page 1
Forum section: electronics / general

author: mblinov
author_rank: Contributor
timestamp: January 13, 2022, 07:14:02 pm
content: Hi everyone,I'm currently using the NXP RT1020 chip on the RT1020 EVK, with the J-Link EDU mini as the debug probe. I’d like to use the SWO functionality of the chip. However, all my text appears garbled - see image below (I'm trying to print"Hello World\n\r"in a loop.)Below I have laid out all the steps I took to try and get to setup SWO tracing on the RT1020-EVK, in the hopes that perhaps some of the more knowledgeable of you will be able to quickly spot a "trap for young players"I've got the board infront of me if anyone needs more info.My Initial setupUsing RT1020-EVK board running at 500MHz, J-Link EDU mini debug probe, board powered by external 5V via DC barrel jackBoard runs perfectly well, USB OTG, SD/MMC, FreeRTOS all work, etc. Normal debugging operations all work via the SWD protocol.To enable SWO in hardware, I followed official instructions to modify the board:Remove 0 ohm resistor R116Populate 0 ohm resistor R425 (I just added a solder bridge)The above instructions are taken straight out of the RT1020 EVK schematic, on page 11:(You can download the schematic from here:https://www.nxp.com/webapp/Download?colCode=MIMXRT1020-EVK-Design-Files, but I've attached the PDF to this post.)On the physical board, they are located here (This is before i removed/added the resistors):Resistor R116 to be removed:Resistor R425 to be added:To enable SWO in software, I followed official instructions   as follows:Create new project, and select checkbox “Enable redirecting printf to ITM”Here I select my dev board... (Please right click the image and select "Open in new tab" to see full resolution)The only thing I changed here is the project name, and project locationAnd here I select "Redirect SDK "PRINTF" to C library "printf", followed by "Redirect scanf/printf to ITM"Finally the project is createdAdd the SWO pin in the MCUXpresso IDEEnable the SWO pin on the MCU (this step is actually redundant as you will see next)Paste in two snippets of code, as officially documented in AN13234For sake of readibility, the two changes that AN13234 asks us to make for the RT1020 are:For config_clock.c, in functionBOARD_BootClockRUN, changeCLOCK_DisableClock(kCLOCK_Trace);/* Set TRACE_PODF. */CLOCK_SetDiv(kCLOCK_TraceDiv, 3);/* Set Trace clock source. */CLOCK_SetMux(kCLOCK_TraceMux, 0);ToCLOCK_EnableClock(kCLOCK_Trace);/* Set TRACE_PODF. */CLOCK_SetDiv(kCLOCK_TraceDiv, 0);/* Set Trace clock source. */CLOCK_SetMux(kCLOCK_TraceMux, 0);And for pin_mux.c, in functionBOARD_InitPins, add the following lines:IOMUXC_SetPinMux( /* Add these lines*/IOMUXC_GPIO_AD_B0_11_ARM_CM7_TRACE_SWO,0U);IOMUXC_SetPinConfig( /* Add these lines*/IOMUXC_GPIO_AD_B0_11_ARM_CM7_TRACE_SWO,0x00F9U);The clock setting (the original code is #ifdef'd out)And the pin mux settingLaunch debug session, break on main, open SWO Trace Config window, select frequency “500MHz” (the system core frequency)Hit “Continue” in debug session (I moved the "PRINTF" statement into the loop to demonstrate the poor printingAt this point I see myCode:"Hello World\r\n"text, but very garbled, as if I have a mismatched core frequency, or some kind of signal problem.This looks like a pretty typical frequency/baud rate mismatch issue, but I’ve tried every frequency under the sun for the SWO frequency under the “SWO Trace Config” settigs window, so I’m wondering if any of you have any ideas.I’m pretty new to all these tools (J-Link, NXP RT chips) but I’ve used SWO succesfully over the ST-LINK V2 (the offical one, not the knockoffs.) with STM32 chips before.Some things I’ve tried:Use different SWO Trace Config frequencyThe core natively runs at 500MHz, but I get a warning popup saying that “for Cortex M7 devices, it might be different”. So I had a look at the core clocks page, and sure enough theres a TRACE clock running at 117.333...MHz, and I’ve tried that too to no avail.I have also tried 24MHz, 48MHz, 100MHz, and 501/505/490/495/488 (see below why 488), none of which gave any better outputTry different SWO Trace Config prescalers (Option varies from 1, 10, 100)Didn’t improve the outputTry using the J-Link SWO Viewer (Version 7.54b)The dialog gives me the option to “autodetect” the core frequency, and it reports 488MHz. Still, I see absolutely no output in the window when I hit “Start”.:https://www.nxp.com/docs/en/application-note/AN13234.pdf:https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/mcuxpresso%40tkb/41/1/How%20To%20Use%20SWO%20Trace%20in%20MCUXpresso%20IDE.pdf

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 13, 2022, 07:19:44 pm
content: Just looks like the typical wrong baud rate. Have you checked it with a scope?

author: mblinov
author_rank: Contributor
timestamp: January 13, 2022, 07:40:23 pm
content: Quote from: SiliconWizard on January 13, 2022, 07:19:44 pmSo I shoved a scope probe into J50, which according to the schematic carries the TDO/SWO signal:I only have an analogue scope, but the signal view in the image is stable and each pulse is at 2.13MHz width. If i try to set that as the SWO frequency (with prescaler of 1), i get nothing.The setup:The signal (stable image):

author: mblinov
author_rank: Contributor
timestamp: January 13, 2022, 09:34:34 pm
content: Hi everyone, just wanted to give a quick update: I connected my J-Link EDU mini to a Nucleo64-L452RE, and I can confirm that SWV/SWO (whatever they call it these days) works flawlessly on this board.So the issue is probably not with the J-Link EDU mini, which is what I was slightly worried was the case. But I can rule that out now.The setup (the ST LINK V2 also worked, but ofcourse that isn't gonna be useful with the NXP board)The SWV console:Core clock is 80MHz.Anyway, I will perhaps post this on the official NXP forums to see what they think.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 13, 2022, 09:45:48 pm
content: From your scope capture, the baud rate is double what you think: you need to take the width of a single bit. So that would be about 4.25 Mbits/s.I'm pretty sure your problem *is* with the baud rate. From your J-link control panel, you have apparently set the baud rate to 4 MBits/s (4000 kHz). So there's a slight mismatch, explaining the corrupted data.4.25/4.00 => that's an error of +6.25 %, which is more than what is usually tolerated for UART communication.My thought is that the core actually runs at 528 MHz, and not 500 MHz as you think - which would not surprise me, since 528 MHz is the default core clock frequency on this MCU, IIRC.528/500*4 = 4.22So, check your clock settings. And it should be fine.

author: mblinov
author_rank: Contributor
timestamp: January 13, 2022, 10:05:48 pm
content: Quote from: SiliconWizard on January 13, 2022, 09:45:48 pmYou're right, damn, how did I miss that!? I guess I was obsessed with the "500MHz" figure as it was what my eyes first latched on to in the clocks configuration page (The AHB_CLK_ROOT), and when I set a variable watchpoint on theSystemCoreClockglobal variable, it reported (and still confusingly reports) as 500000000 in the debugger:I would have found it had I actually spent some time looking at the clocks page.Anyway, thanks a lot, I promise I'll actually read the datasheet next time...