From 32F769IDISCO to Custom Board - Target, PinNames, PeripheralNames & PeripheralPins

Electronics and hardware
1

Hi there! –

(cc @jeromecoutant - on peut en parler en direct si besoin)

My team and I have been working on a custom board based on the 32F769IDISCO. Thanks to ST’s documentation, we were able to get it up and running very quickly. We kept most of the pins the same, especially for the complex things to make debugging easier and to allow us to still use the DISCO for development.

We’ve also created a new target by copying the DISCO. Code compiles and runs, so far so good!

As with our board all the pins, names, peripherals and functions are set in stone we put together a neat little process where we define all the pins in a Google Sheet, export a csv, create an .ioc file with CubeMX and edit the .ioc file from the command line to apply the functions and labels of all the pins defined in the csv. (I can share the script if someone’s interested)

Then we used the STM32_gen_PeripheralPins.py script to generate the PeripheralPins.c and
PinNames.h files.

The script works great but doesn’t take into account our own labels. For that I put together another script to parse the csv and generate a .h file with our all pins. (I can also share this one if needed)

First question: did I miss something in the STM32_gen_PeripheralPins.py script to also generate pin names based on our labels?

Then, we dove into the documentation (mbed/stm/pin configuration) and PeripheralPins.c.

Second question: As we know in advance if we’ll be using alternate functions and the function of each pin, we were wondering if we could comment out all the non relevant information?

For example:

MBED_WEAK const PinMap PinMap_SPI_MISO[] = {
    {PA_6,       SPI_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI1)}, // Connected to SD_SPI_MISO
    {PA_6_ALT0,  SPI_6, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF8_SPI6)}, // Connected to SD_SPI_MISO
    {PB_4,       SPI_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI1)},
    {PB_4_ALT0,  SPI_3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF6_SPI3)},
    {PB_4_ALT1,  SPI_6, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF8_SPI6)},
    {PB_14,      SPI_2, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI2)}, // Connected to SCREEN_BACKLIGHT_PWM
    {PC_2,       SPI_2, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI2)},
    {PC_11,      SPI_3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF6_SPI3)},
    {PE_5,       SPI_4, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI4)}, // Connected to MOTOR_RIGHT_ENABLE
    {PE_13,      SPI_4, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI4)}, // Connected to FMC_SRAM_D10
    {PF_8,       SPI_5, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI5)}, // Connected to BLE_SPI_MISO
    {PG_9,       SPI_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI1)}, // Connected to SENSOR_IMU_IRQ
    {PG_12,      SPI_6, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI6)},
    {PH_7,       SPI_5, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI5)}, // Connected to SENSOR_PROXIMITY_MUX_I2C_SCL
    {PI_2,       SPI_2, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI2)}, // Connected to FMC_SRAM_D26
    {NC, NC, 0}
};

The lines really important to us and related to PinMap_SPI_MISO are:

    {PA_6,       SPI_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI1)}, // Connected to SD_SPI_MISO
    {PF_8,       SPI_5, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI5)}, // Connected to BLE_SPI_MISO

Is it ok to remove the other ones? Will that have a positive impact on anything besides making it clear what is used for what.

Thanks a lot for your help!

Best,
– Ladislas

2

Hi

  • question about STM32_gen_PeripheralPins.py script: this was my “personal” script… I decided some times ago to share it in mbed-os repo, but of course, it is not bug free, and goal has to be precise depending on your requests. If you succeed adding labels in the files generation, I would be very happy to see that my script can be a good starting point for community, and we will merge your patch!

  • question for custom targets: yes, you can remove all the not used pins, change or remove the _ALT pins, …
    Even in json configuration, you should be able to remove the unused feature. targets.json file set the default configuration for each board with the “maximum” features: ADC, DAC, CAN, USB, … etc

Regards,
Jerome

3

Thanks @jeromecoutant for your quick reply! I’ll remove the unneeded pins.

This was my follow-up question: the documentation is not always very clear on where you need to edit/add/remove stuff.

We have a custom_targets.json with the following for our board:

	"LEKA_V1.0_DEV": {
		"inherits": [
			"MCU_STM32F7"
		],
		"extra_labels_add": [
			"STM32F769xI"
		],
		"components_add": [],
		"supported_form_factors": [],
		"features" : [],
		"config": {
			"flash_dual_bank": {
				"help": "Default board configuration is Single Bank Flash. If you enable Dual Bank with ST Link Utility, set value to 1",
				"value": "0"
			}
		},
		"detect_code": [
			"1234"
		],
		"macros_add": [
			"STM32F769xx",
			"HSE_VALUE=25000000"
		],
		"device_has_add": [],
		"device_has_remove": [
			"I2CSLAVE",
			"SPISLAVE",
			"CAN"
		],
		"device_name": "STM32F769NI",
		"overrides": {
			"network-default-interface-type": "WIFI"
		}
	}

We used the "device_has_remove": to remove unwanted/unused functions. Is that enough? Is there anything else to edit?

Also, our MCU is the STM32F769BI (not NI as in "device_name": "STM32F769NI",) should we change that somewhere? It works as is but I want to make sure we won’t be running into some issues if this is not well defined.

Thanks for sharing in the first place! :slight_smile: I’m not so much of a python guy, so my scripts are in Ruby.

I’ve made them available here:

if I get time, I’ll try to edit yours to add the new features.