Part Number: TMS320F280049
Tool/software:
I am working on a project using F280049PMS and we ran into some issues with the LSPCLK.
This is a second iteration of the board but on the DSP side we did not make any significant hardware or software changes. On the hardware, I am using the same crystal (TSX-322520.0000MF20G-AC3) connected to X1 and X2. We have the DSP talking to a ESP using Uart (SCI) and what we have observed is somehow the DSP is doing a baud rate 7 times faster than what we expected. Another observation is when we are using the debugger, the Timing for the SCI module works as expected. It is just when using the board's clock that this happens.
SYSCLK = 100 MHz
PLLSYSCLK = 20MHz (XTAL_OSC) * 10 (IMULT) * 1 (FMULT) / 2 (PLLCLK_BY_2)
LSPCLK = 25MHzBased on the above SYSCLK and a default low speed peripheral clock divider of 4
SCIHBAUD = 0x0SCILBAUD = 0x5D
Based on the arguments passed to
SCI_setConfig(AMPLE_SCI_BASE, DEVICE_LSPCLK_FREQ, 230400, (SCI_CONFIG_WLEN_8 |
SCI_CONFIG_STOP_ONE |
SCI_CONFIG_PAR_NONE));
where
DEVICE_LSPCLK_FREQ = 25MHz
Based on the output of the SCI, the LSPCLK seems to be 175MHz.
The ePWM is working at the correct speed. The same code is able to work correctly on the older revision of the board but hardware wise I am not very clear what can cause this issue, especially since the UART connection are directly pin to pin from DSP to ESP.
Several debug process have been done below:
We ran the sysctl_ex2_xclkout_config.c with our own configuration and GPIO_16 frequency was 12.5MHz. I am not sure if this value makes total sense. I was expecting something around 100MHz.
We also ran other tests:
- We created a project that just initializes the clocks and GPIOs. In the loop in main we set and clear GPIO_7 with no delays and compare the timing with the debugger and without the debugger. They performed the same way.
- We used the macro DEVICE_DELAY_US to create a square wave with GPIO_7 and it worked as expected. Timing was very precise with 10 us. We also test this with and without the debugger.
We are able to work around the issue by putting a multiplier on the LSPCLK when we do SCI setup in the software but it doesn’t seem to be a good solution.
