Evaluation boards arrived from STM

Guys

STM have sent me the Nucleo boards, which their code will eventually support.

These boards are

Nucleo L053
Nucleo F091
Nucleo F103
Nucleo F303
Nucleo F446
Nucleo L476

I already had a Nucleo F334, and I can’t remember whether that was on their list to be supported or not.

I also have a Discovery F4, but I don’t think STM intend to support the Discovery series at all – however I think a number of people on the forum have some form of Discovery F4, so I suspect we will end up supporting it in some way.

PS. The boards have taken a week by Fedex to get from France to Australia, because they were misslabled with the AT rather than AU country code, hence they have been from France to Austria and back 3 times before I rang Fedex to notify them that something was seriously wrong with the addressing of the package(s) – and managed to get them to update the labels

Its strange, as the delivery address was correct, so you;d imagine it would be all handled by bar codes, not by the country code printed on the box, but perhaps they still manually sort stuff!

The barcode there on the label is generated from the destination address a person enters into their system..
And yes, Austria and Australia is the same destination for most parcel services

Well if you want a laugh, here is the track log

29/09/2016 - Thursday
13:49 Delivered VICTORIA AU

09:23 On FedEx vehicle for delivery DERRIMUT AU

08:21 At local FedEx facility DERRIMUT AU

08:21 In transit DERRIMUT AU

Package available for clearance
08:21 International shipment release - Import DERRIMUT AU

28/09/2016 - Wednesday
11:59 In transit SINGAPORE SG

08:31 In transit SINGAPORE SG

04:26 In transit GUANGZHOU CN

03:42 Departed FedEx location GUANGZHOU CN

27/09/2016 - Tuesday
22:11 Arrived at FedEx location GUANGZHOU CN

05:56 On FedEx vehicle for delivery LEOBENDORF AT

04:19 In transit ROISSY CHARLES DE GAULLE CEDEX FR

03:45 Departed FedEx location ROISSY CHARLES DE GAULLE CEDEX FR

03:11 In transit ROISSY CHARLES DE GAULLE CEDEX FR

00:29 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR

26/09/2016 - Monday
22:44 In transit WIEN AT

18:21 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR

13:24 In transit VIENNA AT

05:14 In transit VIENNA AT

Tendered to authorized agent for final delivery
05:00 In transit VIENNA AT

Package available for clearance
25/09/2016 - Sunday
00:33 In transit ROISSY CHARLES DE GAULLE CEDEX FR

24/09/2016 - Saturday
19:39 Departed FedEx location ROISSY CHARLES DE GAULLE CEDEX FR

18:35 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR

03:55 Arrived at FedEx location ROISSY CHARLES DE GAULLE CEDEX FR

23/09/2016 - Friday
20:01 In transit CORBAS FR

20:01 Left FedEx origin facility CORBAS FR

15:30 Picked up VOREPPE FR

08:34 Shipment information sent to FedEx


Your boards traveled around the globe
The most expensive boards ever

I picked up an L476 board this weekend, as my local brick and mortar source had them in stock.

The L476 board does work, but I had an issue with the upload script, so I’ve pushed a totally new version of the nucleoflasher bat file to the tools repo

Also. I’ll need to open another thread, as the L476 seems to have some problem with clock speed.

It appears to be running at 64Mhz not 80 Mhz. (See viewtopic.php?f=3&t=76&start=70#p18464 )

I’ve emailed STM and Wi6 and asked them to investigate as its a problem in the original code produced by Wi6Labs (or its by design that they only run a 80Mhz board at 64Mhz)

Apart from that, things like Blink and PWM work and also SPI works

Roger,

As we have said in our email reply we have chosen to run the L476 at 64MHz. You can change the clock configuration by setting the flag ENABLE_HIGH_SPEED (in hw_config.h) and recompile the library. The clock will be at 80MHz.

The L476 board does work, but I had an issue with the upload script, so I’ve pushed a totally new version of the nucleoflasher bat file to the tools repo
Could you explain us what issue did you have with the upload script? What Windows version are you using?

Thanks

Wi6Labs wrote:Roger,

As we have said in our email reply we have chosen to run the L476 at 64MHz. You can change the clock configuration by setting the flag ENABLE_HIGH_SPEED (in hw_config.h) and recompile the library. The clock will be at 80MHz.

The L476 board does work, but I had an issue with the upload script, so I’ve pushed a totally new version of the nucleoflasher bat file to the tools repo
Could you explain us what issue did you have with the upload script? What Windows version are you using?

Thanks

Why wont I2C work at 80MHz?

does it end up going to fast ?

BTW.

I’ve posted an update to the Dhrystone thread, but the board is indeed defaulting to 64Mhz in the original library.

This makes it only marginally faster than the F103 @72Mz

I think we will need to add an errata page to the wiki, to say that the Nucleo L476 Arduino core runs at 64Mhz and not the published frequency (on the packaging of 80Mhz)

I guess I could build 2 different libs and allow the user to select between 64 and 80mhz but I think we have more important things to spend our time on.

RogerClark wrote:Why wont I2C work at 80MHz?

does it end up going to fast ?

Ah

OK

So if the ENABLE_HIGH_SPEED macro was use in the I2C code, to adjust the settings, it could be made to work ?

Would that means it can still be running, but instead of 100KHz, it would be 125KHz ?
Same thing for 400KHz, it will becomes 500KHz ?
For most devices, it should be a problem.

Wi6Labs seem to have defaulted the SPI to 1Mhz (for 64Mhz clock) but I”m not sure what I2C speed the chose

I’m not sure why Wi6Labs chose 1Mhz SPI when the AVR default is DIV_4 of 16Mhz = 4Mhz. I think it should probably be defaulted to the same as AVR for compatibility, but thats something for the SPI library not these PLL settings

Same thing with I2C really, except I’ve no idea what speed they chose, and I don’t know (without googling) what the default AVR I2C speed is.
I presume its 100kHz

In this case the definition of ENABLE_HIGH_SPEED must alter the initialization of the I2C…. This is strange because HALMX is supposed to read the current clock frequency and make the proper adjustments in initialization of I2C and other peripherals….

Slammer wrote:In this case the definition of ENABLE_HIGH_SPEED must alter the initialization of the I2C…. This is strange because HALMX is supposed to read the current clock frequency and make the proper adjustments in initialization of I2C and other peripherals….

Slammer wrote:In this case the definition of ENABLE_HIGH_SPEED must alter the initialization of the I2C…. This is strange because HALMX is supposed to read the current clock frequency and make the proper adjustments in initialization of I2C and other peripherals….

RogerClark wrote:Wi6Labs seem to have defaulted the SPI to 1Mhz (for 64Mhz clock) but I”m not sure what I2C speed the chose

I’m not sure why Wi6Labs chose 1Mhz SPI when the AVR default is DIV_4 of 16Mhz = 4Mhz. I think it should probably be defaulted to the same as AVR for compatibility, but thats something for the SPI library not these PLL settings

Same thing with I2C really, except I’ve no idea what speed they chose, and I don’t know (without googling) what the default AVR I2C speed is.
I presume its 100kHz

GrumpyOldPizza wrote:

Actually no. The HAL is not that abstract there. For some device it seems that you can just pass in the speed that you want (and it calculates stuff behind your back for the right setup). For some how that are derived from the newer FMP+ I2C core, you need to pass in explicit timing parameters to make it work. Just as a fun side note, the values in the databook are highly questionable, and I found quite a bunch of I2C devices that would refuse to work. Perhaps that’s just a problem with higher APB clocks.

Wi6Labs wrote:
Indeed the I2C clock configuration for L4 doesn’t work like F1. You must calculated for each speed a specific parameter which depends on the system clock.
You can find more information inside the file “twi.h”.

As I understand, CubeMX passes the parameters on registers as they are (at least for I2C)…. For proper operation a rather complex calculation is required, while this is not a big problem, the different parameters for different clocks, is.
I will check the mbed and Chibios how they solve this problem…..

Slammer wrote:As I understand, CubeMX passes the parameters on registers as they are (at least for I2C)…. For proper operation a rather complex calculation is required, while this is not a big problem, the different parameters for different clocks, is.
I will check the mbed and Chibios how they solve this problem…..

OK.

So we could use mbed’s I2C values for 80MHz

We have taken account your remarks about the STM32L4 system clock settings.
A new release will be soon available with the new settings:

• system clock at 80MHz
• SPI default speed at 5MHz
• I2C clock settings updated

BR

Excellent…

Thanks