STM32F767 Chip Code Compatibility

Custom and community boards
1

Hello,

I am looking to create a custom board using the STM32F767ZI chip that comes on the NUCLEO-F767ZI board. However the footprint of that chip is a bit large for what I am trying to fit it on, and a smaller LQFP or BGA package would be better for the size of board being used. What I am wondering is if I switch to say the STM32F767VI in the LQFP100 or TFBGA100, or even other pin count packages, would the code still be directly compatible? Sure it would be missing some GPIO, but I don’t need 144 or more GPIO, so that would be fine

2

We’ve done the process from F769NI (BGA) to F769BI (LQFP) and it works great.

We had issues with the HCE and LSE that mbed defines but did not have them on our board. They were added later to driver the LCD screen.

You’ll need to define a custom target.

More info here:

3

the clock is the first thing that should be checked with a new custom target. For STM devices, there is already a good preparation for choosing different sources like HSE or LSI. The Nucleos use an external clock from the onboard STLink, so HSE must be configured to use a crystal (if included in custom design).

        "config": {
            "clock_source": {
                "help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL | USE_PLL_HSI",
                "value": "USE_PLL_HSE_XTAL | USE_PLL_HSI",
                "macro_name": "CLOCK_SOURCE"
            },
            "hse_value": {
                "value": "25000000",
                "macro_name": "HSE_VALUE"
            }
        },

it maybe necessary also to change the clock frequency. Mbed does some calculations for timer clocks and need to now the main clock frequency, otherwise sleep_for() times would be wrong e.g.

The custom target should also define the correct chip variant. It is used in HAL code and maybe important for some different ressources. You’ll find the device name in mbed-os/tools/arm_pack_manager/index.json.
In many cases, the program will compile with wrong (missing) pinnames, but PinNames.h and PeripheralPins.c should be checked as well. In some cases you’ll find commented lines where more than one alternative function is possible.

4

Yep! Learned that the hard way :smiley:

You mean only if you use a different HSE with a different clock frequency, right?

I’ve found ours, it is:

 "name": "STM32F769BITx",

So where should I change that? :slight_smile:

5

yes

this is the “device_name” property in the target definition. It is also used for an automatic setting for ROM_START and length. When this name is not correct, you see a warning at the begin of the mbed cli scanning.

6

Okay, good thing you pointed that out about the clock, I would’ve had no idea to check that. I think I want to end up using the STM32F767VIT6, and that looks like it should be supported if a new target is defined. Is there a comprehensive guide anywhere about defining new targets? And what do HSE and LSI stand for? I gathered they have to do with the clock, but is there anything else I should know about that?

7

You should start here: https://os.mbed.com/docs/mbed-os/v6.4/porting/porting-custom-boards.html

It’s a bit complexe so take your time and follow the examples as they are to get a better understanding.

Here’s a custom target I’ve made, as an example: https://github.com/ladislas/mbed-cmake-template/tree/master/targets

  • HSE = High Speed External clock
  • LSI = Low Speed Internal clock
8

There are often many clock options, a great tool for the STM32 is CubeMX with a good interactive visualisation of the clock settings. It is also a good helper for planning the IO and other resources.
Althoug it looks complicated at the first sight, in most cases only the PLL setting with multiplier/divider settings need to be adjusted. The system_clock.c is prepared for different clock sources already, that makes it easier.

9

For me it’s still not clear how the clock GUI in CubeMX can be ported to system_clock.c.

As things are working fine without it I did not spend much time on it, but if you have feedback, experience or resources about that, I’m really interested!

10

CubeMX generates also code and puts a SystemClock_Config() in main.c. There you will find similar init code as in Mbed system_clock.c. Of course, the special Mbed macros are missing, but you can compare the settings in the HAL function calls.
For the main clock, first the appropriate oscillator is configured. Then the PLL is activated for the full speed clock. For power savings, this could be left disabled. CubeMX has also a power calculator where you can see the effect of each enabled device.
CubeMX is pretty straight forward, but there is also a good documentation for this tool. You’ll start with selecting the used MCU or to make easier, with an eval board. There you’ll see some enabled devices and the clock settings as used for this eval board and you can modify it.
When starting with a MCU, you should select in the first step the used oscillators in the RCC. Then these are enabled in the clock diagram and you can select further options such as crystal frequency.