Add data about DMA peripheral triggers

[salkinium]

This adds a parser for the IP/DMA-* files for all STM32 devices.

• stm32 data, only has channels (F0, F1, F3, L0, L1, L4)
• stm32-extended data, has streams and channels (F2, F4, F7)
• stm32-advanced data, what the heck?! (H7, L4+)

cc @rleh @chris-durand

[salkinium]

There's also some configuration recommendations per trigger:

• mode (normal or circular)
• direction (m2p or p2m)
• increment boolean
• alignment
• burst

[chris-durand]

STM32F09x devices with the "STM32F091_dma_v1_1" IP also have a request mux like the L4.

[salkinium]

Yeah, this categorization is still messy, cos I don’t have a good overview of the DMA implementations yet.

[chris-durand]

I roughly cross-checked the generated device files with the reference manuals. Almost all data looks reasonable. Only the requests for F09x devices are missing.

[salkinium]

Not just F091 and F098 devices use requests, but also the F030 with size C, and all L0 and L4. ST is weird.

[chris-durand]

what the heck?! (H7, L4+)

The H7 has 3 DMA instances (DMA1, DMA2, BDMA) and two DMAMUX.
They are connected in the following way:

• DMAMUX1 out 0-7 -> DMA1 channel 0-7
• DMAMUX1 out 8-15 -> DMA2 channel 8-15
• DMAMUX2 out 0-7 -> BDMA channel 0-7

Any request line input of the mux can be connected to any output. The mapping between request mux input ids and peripherals (Table 116/119 in H7 manual) is specified in the <RefParameter Comment="Request number" DefaultValue="" Group="" Name="Request" Type="list" Visible="false"> tag in the DMA and BDMA IP xml.

Additionally the DMAMUX also has further trigger and synchronization inputs ...

[salkinium]

Is there a branch for the DMA driver WIP? I want to see what data could be useful for it.

[rleh]

The branch 'feature/dmahal' is available on RCAs private Gitlab.

[salkinium]

Btw, I uploaded some of my experimentation of comparing/compressing the STM32 memory maps as described by the CMSIS header files. Not sure what it all means, but you can get an overview of the different DMA implementations:

• DMA (registers only)
• DMA_Channel
• DMA_Request
• BDMA
• BDMA_Channel
• MDMA
• MDMA_Channel
• DMAMUX_ChannelStatus
• DMAMUX_RequestGenStatus

[rleh]

The DMA data is not accessible from the modm build system:

$ print(device.get_driver("dma"))
{'instance': ['1', '2'], 'name': 'dma', 'type': 'stm32-stream-channel'}

[salkinium]

The DMA data is not accessible from the modm build system:

What :target were you using? Maybe I missed some stm32 family or messed up the device file.

[chris-durand]

What :target were you using? Maybe I missed some stm32 family or messed up the device file.

We were using a STM32F4 Discovery example (stm32f407vgt). It seems child elements are discarded when the parent node has a "value" attribute.

[salkinium]

It seems child elements are discarded when the parent node has a "value" attribute.

Oh yeah 🤦‍♂️
I remember now this was an issue with choosing only a subset of XML to later be able to map it losslessly into a py-dict/JSON-like structure. The value="value" attribute replaces the <node>value</node> to avoid some edge-cases during conversion.
I need to raise an exception when trying to set both value + children.

[salkinium]

Ok, I fixed this by using the position attribute, analog to core/vector.
However, in order to preserve the driver/instance semantics, I moved the additional information into their separate nodes with an instance attribute <streams instance="1">.

[rleh]

This <channels> does not know to which instance it belongs.

modm-devices/devices/stm32/stm32f1-03-c_d_e.xml

Lines 227 to 228 in d02739c

	<instance value="1"/>
	<instance value="2"/>

@salkinium

[salkinium]

Thanks, fixed!

[chris-durand]

@salkinium Thanks for the great data.

Unfortunately, some data is still missing. ST wouldn't be ST if they didn't prepare a special surprise for us. Most F0 and all F3 devices have an annoying DMA remapping feature. To use some combinations of peripherals and channels certain bits in SYSCFG_CFGR1 have to be set.

[salkinium]

ST wouldn't be ST if they didn't prepare a special surprise for us. Most F0 and all F3 devices have an annoying DMA remapping feature. To use some combinations of peripherals and channels certain bits in SYSCFG_CFGR1 have to be set.

Oh, FFS.

[salkinium]

Can you check if this is somehow encoded in the raw CubeMX data? Otherwise I'd have to manually add it like the AFIO for STM32F1/L1

[rleh]

There seems to be some data:
E.g. in db/mcu/IP/DMA-STM32F303_dma_v1_0_Modes.xml(line 96)

<RefParameter Comment="DMA Remap" DefaultValue="HAL_REMAPDMA_ADC24_DMA2_CH34" Group="" Name="DMA_Remap" Type="list" Visible="false">
  <PossibleValue Comment="ADC2 and ADC4 DMA remap" Value="HAL_REMAPDMA_ADC24_DMA2_CH34"/>
  <Condition Diagnostic="" Expression="(ADC2_Remap&amp;(Instance=DMA2_Channel3))|(ADC4_Remap&amp;(Instance=DMA2_Channel4))"/>
</RefParameter>
[...]

Corresponding table in the F303 datasheet:

[chris-durand]

CubeMX generates something like __HAL_DMA_REMAP_CHANNEL_ENABLE(DMA_REMAP_USART1_TX_DMA_CH4);
The data we need is in the ST HAL headers, not in CubeMX.

[rleh]

Something like this:

<remapping>
  <remap_group>
    <default>
      <signal dma_instance="2" dma_channel="1" driver="adc" instance="2" name="dma"/>
      <signal dma_instance="2" dma_channel="2" driver="adc" instance="4" name="dma"/>
    </default>
    <remapped>
      <signal dma_instance="2" dma_channel="3" driver="adc" instance="2" name="dma"/>
      <signal dma_instance="2" dma_channel="4" driver="adc" instance="4" name="dma"/>
    </remapped>
    <!--
     Remap bit "SYSCFG_CFGR1_ADC24_DMA_RMP" can be computed
     from <signal> elements inside <remapped> above
    -->
  </remap_group>
</remapping>

[salkinium]

cc @rleh @chris-durand

I've added these remappings manually from the F303x6/8 RM, so we can discuss the formatting. I believe this is a compact and unique mapping, but I have to check this computationally.

This would require the dma driver module file to compute the conflicts somehow, but the information is all here.

[salkinium]

Note that similar to the STM32F1 remap, the bit position for the config registers is directly encoded here, to be independent of STs naming register conventions.

[salkinium]

(position / 32) + 1 gives the registers number, here CFGR3. Same idea used for AFIOx in STM32F1 GPIO remappings.

[salkinium]

No clue why ST thinks it needs two mappings for this value. I'm not sure if this isn't a copy-paste error in the PDF.

[salkinium]

I don't see an advantage for also adding the 0b11 encoding here, it does the same thing as the 0b00 encoding.

[salkinium]

The STM32 reference manual incredibly inconsistent. All F3 reference manuals say this:

With the corresponding table entry:

But the F373 reference manual says for this:

This is a mistake, the table is the same for all F3 and the CubeMX data confirms this. ST needs to get their shit together.

[salkinium]

Oh gawd, this is a gem, see dma2ch1. Note that this writes both bit 72 and bit 73.

[salkinium]

Right, so… ADC2 can be remapped entirely to DMA2 or DMA1 with bit 73:

But this bit doesn't set the channel, nono! DMA 1 channel is selected with bit 72:

And DMA2 channel is selected with bit 8, which also remaps ADC4.

Good lord, ST, really?

[salkinium]

@rleh @chris-durand These remaps are some ugly constraints, you're going to have to be smart about the channel scheduler with this.

[salkinium]

I've added the remaps groups now in an automated fashion, please do a spot check for your devices, to see if there are any systematic errors in this. I've extracted the F0/F3 remap sets manually from the reference manuals, the may be faults in there.

[salkinium]

I'll be merging this into modm-devices to prevent this work going stale and to allow implementing an (incomplete) API in modm already.