Custom STM32F469 board with Standard Peripheral Library 1.8.0: Clock wrong after power up, correct after several resets

[Digimorf]

Posted on June 27, 2018 at 23:15

Hello,

I am developing a custom board that mounts a STM32F469 MCU. The board is very simple, and the circuit embeds only the main 8Mhz crystal and the RTC 32.768 one. No embedded peripherals except for a couple of status LEDs and a MUX 74*138 chip used to select memory banks on an expansion BUS based on the FMC.

Crystals are more or less equivalent to the 469 Discovery, they are very close to the CHIP and the capacitors are the ones required by the crystals. ''Electrically'' speaking everything should be correct since the board works fine.

The board mounts several headers to connect peripherals, so I can say that this is a minimal STM32F469 system. I have developed many drivers for this system so far, SRAM on FMC, SD over SPI, Usart etc, now I am fine tuning a VGA driver. Each driver can be included or not at the startup, so, for now, I am fine tuning the VGA driver and in this specific case is the is the only one started in the project.

All the firmware at the moment is based on the Standard peripheral library 1.8.0, but I think to clean everything by using my own references to registers.

Anyway, the VGA driver uses an external 12-bit resistor DAC, plus two simple GPIOs for H and V synchros. The signal is generated by a DMA that streams a scanline n the GPIO port. This stream of data drives also the horizontal sync, so no PWM channel is needed for the hsync pulse. The DMA is triggered by TIM8 clocked at a pixel clock frequency very close to the VGA standard, so no problem with that. I can generate a horizontal resolution up to 640x480.

The weird problem that I am experiencing is that when I power on the board, the clock seems to run slower than it is supposed to run. The scan line, which is generated by theTIM8 that trigs the DMA, seems to take more time. BUT, if I push the reset button (this is a simple reset circuit with a pull-up resistor) the speed increases. Sometimes after the first reset it fixes and goes to the correct one, sometimes it needs more resets to adjust.

As you can see from pics, the monitor doesn't catch the signal until the third reset. Really weird.

If the clock wasn't properly configured the TIM8 shouldn't generate the signal at all, on the other hand, the circuit should be correct, otherwise, the clock shouldn't work correctly. It seems that the reset is needed to stabilize the clock. 

I have noticed that the file 'system_stm32f4xx.c' in the examples of the SPL1.8 seems not really configured for the 469, so I tried to see what is generated by the CubeMX for the HAL. Of course, everything is different but, there are more things configurated. For example, the PLLSAI that within the cubeMX clock configuration could be selected to generate the 48Mhz clock for the USB. This configuration is missing in the system file of the SPL, but in the 'stm32f4xx_rcc.c' the driver the function to configure it is present, with explicit references to the stm32f469 chip. So my impression is that the support of the 469 is incomplete. 

I have built four prototypes and the result is the same on all of them. 

In your experience have you ever had something similar? Really weird. I haven't posted any details for now, just would like to have some more ideas to start from.

By the way, the board at work on a Colecovision emulator that I wrote:

https://www.youtube.com/watch?v=ZZ7kFWV-itE

Thanks.#stm32f4 #frequency #custom-board #standard-peripheral-library #stm32f469 #power-on #clock

[STOne-32]

Posted on June 28, 2018 at 01:17

Hi,

can you try to increase the default software timeout of all HSE , LSE clocks before the Ready bit is set. Same for PLL lock as well. You should find it in the Clock setup functions. It may happen that with your selected crystal start-up it is a bit longer after power Up. When doing a soft reset the clocks may be stabilized and ready after the expired timeout.

hope it helps you

Cheers,

STOne-32

[Digimorf]

Posted on June 28, 2018 at 07:29

Thank you very much for your suggestions, I will try to tune the timeout of those settings.

Maybe I could try also to write my own System Init function and use it in the startup file of the project (*.s).

I will keep you updated, 

Thanks.

[Digimorf · Accepted solution]

Posted on July 04, 2018 at 09:34

Hi,

After several tests, I decided to start with a new and fresh project. So I rebuilt everything and now the clock is perfect as expected. I believe that something went wrong when I imported the project after a big update. I have tested it again, and I had no problems.

So thank you for the suggestion, it helped me, sometimes things are more simple than people expect