How to extract alternate function mappings from CubeMX's XML database files?

[ceremcem]

I'm using CubeMX's XML files as "Datasheets in database format" in my own "RTOS Hardware Configuration Tool". However, I couldn't find out how to extract the "Alternate Function Mapping" from those XML files:

The `mcu/config/llConfig/ADC-STM32F0xx_DefMapping.xml` is promising but I still couldn't figure out how to translate - eg. - `GPIO_AF2_TIM5` to anything.

Any ideas?

[TDK]

GPIO_AF2_TIM5 just expands to 2 through a define. Same as all other GPIO_AFx_* evaluating to x. The TIM5 part is just to make things a bit more readable. Is that what you're after?

#define GPIO_AF2_TIM3          ((uint8_t)0x02)  /* TIM3 Alternate Function mapping   */
#define GPIO_AF2_TIM4          ((uint8_t)0x02)  /* TIM4 Alternate Function mapping   */
#define GPIO_AF2_TIM5          ((uint8_t)0x02)  /* TIM5 Alternate Function mapping   */
#define GPIO_AF2_TIM12         ((uint8_t)0x02)  /* TIM12 Alternate Function mapping  */
#define GPIO_AF2_SAI1          ((uint8_t)0x02)  /* SAI1 Alternate Function mapping   */

[ceremcem]

For example, in order to configure STM32F030F4Px's PA3 as USART1_RX, I need to set the relevant Alternate Function nibble to "1", as stated in datasheet.

What I could get from mcu/config/llConfig/GPIO-STM32F0xx_DefMapping.xml is that there are 3 "Item"s containing search word "usart1":

* An item contains "GPIO_AF0_USART1" string

* An item contains "GPIO_AF1_USART1" string

* An item contains "GPIO_AF7_USART1" string

How would I know which Item to parse?

In the file mcu/IP/GPIO-STM32F031_gpio_v1_0_Modes.xml, there is a structured data at: IP.GPIO_Pin.9 indicating the following:

This allows me to conclude that I need to set AF1 in order to configure PA3 as USART1_RX. However, this information is inside a file named *STM32F031*.xml where I'm interested in STM32F030F4Px.

How can I know which "*Modes.xml" file applies to STM32F030F4Px?

[ceremcem]

Does the following information indicate that I need to refer to GPIO-STM32F031_gpio_v1_0_Modes.xml for STM32F030F4Px:

mcu/STM32F030F4Px.xml: <IP ConfigFile="GPIO-STM32F0xx" InstanceName="GPIO" Name="GPIO" Version="STM32F031_gpio_v1_0"/>

[Matthijs Kooijman]

I was just looking for exactly the same thing and then found your post. From the looks of it, your posts seem right, by using the `<IP>` tag you can find which GPIO config file to parse, and then I expect that the signals from e.g. `STM32F030F4Px.xml` should match the ones in `GPIO-STM32F031_gpio_v1_0_Modes.xml`. Note that the latter seems to add info on the AF needed, but the former includes signals that have no AF mapping such as ADC assignments.

[Uwe Bonnes]

It is a long way to scan through the XML files. I do this in ethernut sourceforge svn head to produce headers like

#define I2C1_SCL_FUNC           3

#define I2C1_SDA_FUNC           4

...

       ((gpio == PA09) && (func == TIM1_CH2_FUNC           )) ? 1 : \

       ((gpio == PA09) && (func == I2C1_SCL_FUNC           )) ? 4 : \

       ((gpio == PA09) && (func == USART1_TX_FUNC          )) ? 7 : \

...

withe python script.

[ceremcem]

I don't get the idea here. Can you please describe the algorithm step by step?

[ceremcem]

STM32F031_gpio_v1_0_Modes.xml is a dead end (or I couldn't figure out how to interpret it). Can you use that file to obtain AF mappings?

[Matthijs Kooijman]

Well, it looks like you could find a pin in STM32F030F4Px.xml, e.g.

        <Pin Name="PA0" Position="6" Type="I/O">                               
                <Signal Name="ADC_IN0"/>                                       
                <Signal Name="RTC_TAMP2"/>                                     
                <Signal Name="SYS_WKUP1"/>                                     
                <Signal Name="USART1_CTS"/>                                    
                <Signal IOModes="Input,Output,Analog,EXTI" Name="GPIO"/>       
        </Pin> 

And then in GPIO-STM32F031_gpio_v1_0_Modes.xml, find the corresponding data:

    <GPIO_Pin PortName="PA" Name="PA0">
        <SpecificParameter Name="GPIO_Pin">
            <PossibleValue>GPIO_PIN_0</PossibleValue>
        </SpecificParameter>
        <PinSignal Name="RTC_TAMP2">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF0_MCO</PossibleValue>
            </SpecificParameter>
        </PinSignal>
        <PinSignal Name="SYS_WKUP1">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF0_MCO</PossibleValue>
            </SpecificParameter>
        </PinSignal>
        <PinSignal Name="TIM2_CH1">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF2_TIM2</PossibleValue>
            </SpecificParameter>
        </PinSignal>
        <PinSignal Name="TIM2_ETR">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF2_TIM2</PossibleValue>
            </SpecificParameter>
        </PinSignal>
        <PinSignal Name="TSC_G1_IO1">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF3_TSC</PossibleValue>
            </SpecificParameter>
        </PinSignal>
        <PinSignal Name="USART1_CTS">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF1_USART1</PossibleValue>
            </SpecificParameter>
        </PinSignal>
        <PinSignal Name="USART2_CTS">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF1_USART2</PossibleValue>
            </SpecificParameter>
        </PinSignal>
    </GPIO_Pin>

Now, if you want to want to know the AF mapping for e.g. USART1_CTS, you just look at the PinSignal entry for that, find the GPIO_AF1_USART2 there, and extract the "AF2" part.

        <PinSignal Name="USART2_CTS">
            <SpecificParameter Name="GPIO_AF">
                <PossibleValue>GPIO_AF1_USART2</PossibleValue>
            </SpecificParameter>
        </PinSignal>

It seems you still need the second file, since that defines which signals are available exactly on this pin on this chip, while the second file defines a lot more signals, probably the union of available signals on this chip for all chips from this particular family.

Does that help?

(note that I'm not at all sure that what I'm saying is the best or even a fully correct way of approaching this, but from looking at the XML files, I think this would make sense)