Bad news,
what I have thought to work actually doesn't. As I was worried, the variation of the frequency generates a very shaky and unstable video signal. I am not showing here the code implemented so there won't be confusion, but things don't work and probably I have to change the clock source, the peripheral clock frequency, and the PWM signal.
Let's see what's going on...
The video signal is hooked by this CRT monitor that I always use in my tests for VGA video generation. The problem here is that horizontally, and apparently, randomly the lines of the image are drawn from different starting points. In my experience, this defect may be caused by two problems.
1. Random interrupt latency causes the lines to be drawn at different starting points.
2. Frequency instability.
Frankly, I don't think it's a question of interrupt latency, the main loop of the application is empty, and nothing else is running. So it might be the configuration of the clock.
I had some concerns about a possible clock configuration issue when I saw that both cores have been configured at 100MHz in the "Empty project" example where I started from. This MCU is said to have the cm0+ clocked at 100MHz, and the cm4 clocked at 150MHz but in this example, it isn't.
I went a bit deeper into the clocking system, and the FLL which is used here as a source clock can't go beyond 100MHz. The PLL must be used if you want to clock the cm4 at 150Mhz, but at that point, as consequence, the peripheral clock goes off the allowed range (<=100MHz), so you have to set its divider to 2, at least.
I used the IMO clock source (8MHz) for the FLL so far, but wait, I saw that the kit has the ECO clock connected to a 24MHz crystal, the ECS-240-8-30B-CKM. In the manual there is the schematic:
and 24MHz clock could give me more chances to obtain a good frequency to use for my VGA signal. So I configured the clocking system to use the ECO clock.
The great thing that I saw in this configurator is that you can set several parameters for the crystal!
HOW COOL IS THAT?
I immediately downloaded the datasheet of the crystal to get the correct parameters, here's the link:
After that, I had to redo the math again for the TCPWM counter in the same way I did in my previous post. This time I will configure the PWM as asymmetrical using CC0 and CC1 as limits for the negative pulse, so I can perfectly align the HSync at the end of the scanline, between the front porch and the back porch. Moreover, I can use the CC0 match (when the sync pulse start) IRQ to handle the scanline counter, and the TC IRQ to start sending pixels.
Now the variation of the frequency is 0.001% of 75MHz or 750Hz, so the scanline should be stable enough.
Let's see how it goes now...
Sorry for the super quick video but, yeah, success! Stable, nice, and clean.
In the next part the code.
Top Comments