Clock source on STM32 Nucleo-F411RE

Questions » Clock source on STM32 Nucleo-F411RE

Josh Grauman

8 years, 3 months ago.

Hello all,

I have a ST Nucleo board (F411RE), and I am trying to figure out why the serial links are flaky. Whether it be downloading programs to the board using usb on the stlink side of the board, or using the serial port directly on the headers, or sending serial data through stlink as a serial port, the uarts sometimes work fine, and sometimes don't. At first I thought it might be noise, but now I'm wondering if it might be clock error. So, my question is about the source of the clock on these Nucleo boards. I see there is an 8MHz crystal on the stlink side of the board, and think I read that the chip on the stlink side of the board can generate a clock from that to clock the stm32f411. But I'm thinking maybe the mbed code is just initializing the stmf411 to use the internal rc osc, which maybe is a little off and so the uart isn't timed perfectly and thus the error. I'm using mbed 2.0 code compiled using gcc-arm on my local machine. I just exported a project from the mbed 2.0 online compiler and compiled it on my local machine.

So...

1) How can I tell which clock source is being used for the stm32f411?

2) How can I switch the clock source? Are there mbed functions to do this, or do I need to look up registers on the stm32f411 and do it by hand? Alternately, where do I look in the mbed code to just alter where it is setup there?

3) Can I just solder on a crystal and caps to the board and it will use the new crystal? What freq crystal should I put on to be compatible with mbed code and/or what/where do I need to change the code to do this?

4) Any other ideas about why the serial links are flaky? Does it sound plausible that it could be the error on the internal rc oscillator causing the serial link to sometimes work perfectly for a while, and later miss a lot of bytes sent?

Thanks so much for any help/info!

Josh

I cannot answer your question directly but I can give you some side information.

Please refer following page and check SB16&SB50 connection.

/users/kenjiArai/notebook/nucleo-series-clock-structure-and-xtal-oscillation/

Most of the board uses 8MHz XTAL clock from ST/Link circuit.

Please check clock frequency using following software.

/users/kenjiArai/code/Nucleo_F411RE_SysClk/

The software does NOT affect any current F411 board configuration but just check a system frequency.

Frankly speaking, I believe (only my guess) your problem is not related mbed clock source.

posted by Kenji Arai 19 Jan 2016

1 Answer

Sanjiv Bhatia

8 years, 3 months ago.

Agree with Kenji. What are the specifics of the issue ? The root cause could be related to the serial port routines and/or some IRQ routine causing corruption of the serial port traffic. Try to isolate your code by creating a small routine to just spew out lots of serial port data to the host PC. Once this data transfer is deemed to be stable then proceed forward to debug the issue. You may also wish to consider to slow down the serial port data rate during your testing.

Thanks for both of your thoughts. The program was already minimal. Even as it is, the serial link is very unreliable. It works sometimes for a while and then stops, or I get some of the numbers but not others. I looked up the internal rc oscillator, and the st datasheet says it is factory callibrated to within 1%. So if that is the case, than I agree that it couldn't be causing the error.

#include "mbed.h"

Serial ser(PA_2, PA_3);

int main()
{
  int i=0;
  ser.baud(9600);
  ser.format(8, SerialBase::None, 1);
  while(1)
  {
    ser.printf("%d\r\n", i++);
    wait(0.1);
  }
}

And here was some sample output to my serial terminal:

posted by Josh Grauman 19 Jan 2016

Josh - thanks for your code post. Try to test the same with a different UART. With PA_2 & PA_3 you are bonding to UART_2 (Serial2). Try the same test with UART_1 (Serial1) and post your results.

https://developer.mbed.org/platforms/ST-Nucleo-F411RE/

The reason is due to the following thread which is noting possible issues with multiple UARTs being active which may or may not be related to your issue.

So try with PA_9 and PA_10 for TX & RX, respectively.

On the accuracy, at 9600 baud you should be fine - even 5% tolerance is fine at this very slow baud rate.

Also, can you increase the delay of the wait to be longer - ie. wait (2); - then do you get reliable results with the host PC ? Why not crank up the baud rate to 115.2k ?

Too many windows open - sorry - could not locate the reference from this website on the multi uart issue someone else has raised. Will keep searching..

Can you try the following sample program and change the pins to suit - does it work for you ?

https://developer.mbed.org/teams/Cortex-challenge-team/code/Nucleo-UART/

Let me see which STM32F4 board we have around here....

01-20-2016 Ok found the board it is the Nucleo STM32F401RE so hope it is ok for this review..

try the following code which is working well on my side:

#include "mbed.h"

//------------------------------------
// Hyperterminal configuration
// 9600 bauds, 8-bit data, no parity
//------------------------------------

Serial pc(SERIAL_TX, SERIAL_RX);

char i;

int main()
{
    pc.baud(9600);

    while(1) {
        pc.printf("hello %02x\r\n",i++);
        wait(0.1);
    }
}

borrowed some of this code from here:

https://developer.mbed.org/teams/ST/code/Nucleo_printf/

the results are positive using Realterm @ 9600 baud:

/media/uploads/juthi/realterm.png

and here is the same positive output using 115200 baud:

/media/uploads/juthi/realterm_115200.png

PS: Since the USB Serial port is virtual (ie. CDC model) - do not believe that the baud rates will impact the referenced testing when using the USB interface. It is when you plan to interface with an external micro / interface that is operating @ 9600 baud, 115200 baud, etc. then you will need to be sure you prime the s/w configuration to match the mated external hardware. Curious to see your test results.

Correcting my note - the baud rate does matter with Realterm. Must set for 115200 if using this baud rate with MBED, etc.

posted by Sanjiv Bhatia 19 Jan 2016

Josh Grauman

Important changes to forums and questions

8 years, 3 months ago.