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.
I am using 'uart_tx_multibyte_fifo_dma_interrupts_LP_MSPM0G3507_nortos_ticlang' project example to evaluate my UART application with DMA. I used UART3 instead of UART0. It is working perfectly fine (I can see data coming out on UART Tx line) when I use the below configuration.
CPU clock source : SYSOSS (CPU,MCLK,ULPCLK - 32MHz)
CPU clock frequency - 32MHz
UART3, Baud Rate 4Mbps, Oversampling 8
I am using J-Link plus debug probe to program the microcontroller.
When I change the clock configuration and enable SYSPLL2X to clock the CPU (now CPU,MCLK,ULPCLK - 40MHz), then my code stuck in below while loop in the routine SYSCFG_DL_SYSCTL_init ()
/* Check that SYSPLL is disabled before configuration */
while ((DL_SYSCTL_getClockStatus() & (DL_SYSCTL_CLK_STATUS_SYSPLL_OFF))
!= (DL_SYSCTL_CLK_STATUS_SYSPLL_OFF))
{
;
}
Not sure what is happening. I tried disconnecting the debug and power cycled the microcontroller unit. Still nothing coming out on the Tx line. Am I missing anything?
Any help will be highly appreciated.
Thanks & Regards
Vijaya
Hi Vijaya,
I have tested your settings with SYSPLLCLK2x set to 40MHz and sourcing to MCLK, with UART3: 4 Mbps, 8x oversampling and using the uart_tx_multibyte_fifo_dma_interrupts example.
Please enable the "check for clock stabilization" setting that is in SYSCTL. When this was not enabled the program would wait at while(false ==gDMADone).
Regards,
Luke
Hi Luke,
Thanks a lot for quickly checking this.
I enabled "check for clock stabilization". But the data that is coming out on Tx line is not correct. Mostly it is some junk data with framing errors. When you tested, did you get chance to verify the data that is coming out on Tx?
I didn't see any problem reported in errata related to PLL. This is the 4th sample I am testing. But overall I think, when PLL is used, system is not stable and results are not consistent.
Thanks & Regards
Vijaya
Hi Vijaya,
I was using a logic analyzer to verify the data, below is a screenshot of the scope. I have tested on 2 different launchpads with UART3 on PA25 and PA26. The clock stabilization check is used to verify that the clock system is stable and consistent.
Regards,
Luke
Hello Luke,
Please see my response below. How to share the sysconfig file in this forum? Tried using insert->image/video/file. But unable to upload it.
1) I am not using the the Launch pad. We got MSPM03507 (LQFP-64) samples and made breakup boards with these ICs with an intention to use them in our target boards. I am using pin 6 (Rx) and 7 (Tx) for UART3. I am testing the breakup boards in both ways...i.e. powering them separately or connecting them to final hardware.
I am using J-Link Plus Debugger to connect to SWD interface.
2) Attaching the screen shots of logic analyzer captures in both working and non working case. (Logic analyzer settings are same in bot cases)
Working case (No SYSPLL, CPU clock - 32MHz, 4Mbps Baud rate, Oversampling 8)
Failed case (SYSPLL2x enabled, CPU clock -40MHz, 4Mbps Baud rate, Oversampling 8)
Code is exactly same as the one used in the example 'uart_tx_multibyte_fifo_dma_interrupts_LP_MSPM0G3507_nortos_ticlang' except for changes to UART3 references.
3) I am using mspm0_sdk_0_56_00_01_eng SDK.
Please let me know if you need more details.
Thanks & Regards
Vijaya
Hi Vijaya,
It looks like the baud rate is off and case with 40MHz clock is faster. It looks like you're using the Saleae, there should be an auto-baud rate detection if you want to see what the baud rate is getting sent.
I'm attaching my project with the UART3 using pins 6 and 7 at 4Mbps and MCLK, ULPCLK at 40MHz. Can you import and run this?uart3_4Mbps.zip
Using insert -> image/video/file then clicking the upload button should load your file explorer, from there navigate to the project and select the .syscfg file.
uart_tx_multibyte_fifo_dma_interrupts.syscfg
Regards,
Luke
Hi Luke,
I couldn't find auto baud setting in Saleae, so I manually calculated the baud rate (as suggested by Saleae). It is coming as 4.762Mbps. When I used this baud rate setting then data is appearing properly on logic analyzer. I think, for some reason, UART is not working at set baud rate.
So far, I am unable to use the project you sent. Somehow I am not able to download to the target even after changing the debugger connection to 'SEGGER J-Link Emulator'. I need to look into this. But a quick look at .syscfg shows, in my project I used clock tree to configure clock settings and enabled 'use clock tree'. Where as I think you did clock settings in a different way.
I am attaching the project I used here. uart_tx_multibyte_fifo_dma_interrupts_LP_MSPM0G3507_nortos_ticlang.zip
Please let me know if you need more details.
Thanks & Regards
Vijaya
Luke,
I used the .syscfg file you shared in my project, and things started to work. UART is transmitting data at set baud rate.
As I mentioned above, the only difference is I used clock tree to configure clock and checked 'use clock tree' under SYSCTL. Where as in .syscfg you shared, the same clock settings were done directly in SYSCTL. Clock setting wise, I don't see any difference in both cases. But when I used clock tree things are not stable.
Thanks & Regards
Vijaya
Luke,
Even though the clock setting are same when configured through SYSCTL and Clock Tree, some how the generated code is different. And when I used clock tree, then SYSPLL is not stable. Is there a problem with using clock tree?
I am moving from sample codes to my actual application code. Just to conclude on this, if there is a problem with clock tree then I will refrain from using it in my program. If there is a problem with PLL itself then, I will stick to internal/external clock without using PLL. Or am I missing anything?
Thanks & Regards
Vijaya
Hi Vijaya,
You are right the clock tree is generating the wrong set of code, we will be fixing this in a future update. Using the SYSCTRL will be the best for your development currently.
Regards,
Luke