After playing for some days with the boards - a warning : The implementation of the mbed library needs a lot of improvement to use this boards ! The processor is running at 16 MHz and I'm wondering about the slow SPI speed... Most of the Features from the list above are not implemented today. If ST want to advertise with "mbed enabled" they have to spend more time. Also they did not spend the 10 cent for a crystal to have a stable timing source for the PLL...

Without a solid debugger - wait for a better implementation or you will wast your time.

Peter, (a experienced mbed user )

According to the schematics (and I can see it on the photos), there is an 8MHz crystal feeding the external oscillator pins.

Have you tried configuring the clock control register(s) to enable the external oscillator and use it to drive the PLL for the system clock? According to the F401 reference manual, the device automatically uses the internal 16MHz internal clock (HSI) on reset. It looks like you have to manually configure the use of the external oscillator (HSE) through the main PLL in order to achieve higher system clock speeds (e.g., the max of 84MHz). See section 6.2 and 6.3 of the F401 reference manual for details.

This board is currently in the mail on its way to me, so I can't actually verify this yet. Once I get it, I'll try to do the clock configuration myself and let you know how it goes.

Here is a longer list of known issues: https://groups.google.com/forum/#!topic/mbed-devel/Z6xw7MTR7Aw, without a reaction yet. So not surprised if STM just hopes the code randomly fixes itself (or the community does it).

Well, I'm disappointed.

I received my Nucleo-F401RE today and Peter was absolutely correct. Contrary to *all* of the photos I've seen of this board (including the ones on mbed.org, ahem) the F401RE *does not* come with the external oscillators X2 (for the RTC) and X3 (for the HSE). In many countries this would be considered false advertising and is a serious offense.

That said, I think it may still be possible to configure the system clock to hit 84MHz by driving the PLL with the internal oscillator (HSI). I'll try to give it a shot this weekend.

I'd be nice to get some sort of official acknowledgement and/or apology from STM and/or mbed.org on this pretty glaring error.

Hello Alex, you can use my code http://mbed.org/users/dreschpe/code/ST_401_84MHZ to speed up the board, but I have not solved the timer problem. All wait`s are 5.25 x to fast.

HI Alex (et al),

The Nucleo platform pages, photos and pinout images on mbed were done before the official Nucleo launch and are based on engineering samples. I can confirm that the final boards do not come with oscillators on X2 and X3, and to avoid further confusion we will update the images.

Thanks to Peter Drescher for the detailed investigation.

Cheers,
Mihail

There has also already been an 'investigation' with alot more issues, in the link I posted few posts back. Is there any response either from mbed or ST regarding it? (Regarding Peters code, why is it set at 16MHz, it simply makes no sense).

Hi Erik,

We have forwarded this thread to ST for their input on these issues,

Thanks,

Dan

Thanks everyone for the quick responses!

Peter - Your code looks good, thanks. That's one less thing I have to figure out myself :)

Erik - The 16MHz for the HSI in Peter's code isn't really something you can set. It's 16MHz, period, because that's what's provided on the chip. If you're asking why they chose 16MHz in the hardware design, then that's a question only STM engineers can answer.

@Alex, that was not what I meant (although I see now it wasn't very clear). The HSI being 16MHz is fine, pretty regular choice, on Freescale boards it is 'only' 4MHz for example. But that is irrelevant, the issue is why doesn't it run at 84MHz by default? Why doesn't the code automatically initialize the PLL? There is only one other board which does that, which is the LPC812. However the LPC812 is a low power 8-bit uC replacement. The 401 is a core M4F, that is not something you want to run way slower than it is supposed to run at.

All other boards initialize the PLL (or FLL in case of KL05, but same story). Why not the ST ones?

The timer problem is fixed. A call to SystemCoreClockUpdate(); has updated the SystemCoreClock var.

I think the Nucleo boards had to be finished to the embedded systems. Quick ....

5+++ it cost me $ 20 including shipping

Hello all, What is the current status of Nucleo STM32F401 board? Are the mbed libraries mature enough?

Hi C T

This is actually an old thread and many new versions were published by ST since the very first post. The story about the clock is now solved.

Have a look to the ST SDK Changes log page

SeaFood

As a non-ST employee (sorry Sea Food, but he/she might not consider you the must unbiased person regarding this topic :P), who has been critical regarding the initial versions of the mbed lib for Nucleo targets: It is fine now. Oh there are a few things which can still be improved imo, but it is mature and overall does the job fine.

lol Tx Eric for the neutral feedback :)

Thanks for all answers. I'll begin to prepare some training materials on Nucleo boards so i just wanted to know it's mature enough to do the job. mbed is becoming something more exiting everyday :)