modm-io/modm-devices

Curated device data for all AVR and ARM Cortex-M devices

Curated data for AVR and STM32 devices

This repository contains tools for extracting data from vendor sources, filtering and reformatting them into a vendor-independent format.

This data is used by the modm project to generate its Hardware Abstraction Layer (HAL), startup code and additional support tools. Please have a look at modm's platform modules for examples on how to use this data.

These tools and this data set is maintained and curated by @salkinium only at modm-io/modm-devices. It is licensed under the MPLv2 license.

Currently data for 4360 devices is available. Please open an issue or better yet a pull request for additional support.

Family	Devices	Family	Devices	Family	Devices
AT90	12	ATMEGA	352	ATTINY	148
NRF52	7	RP20	1	SAMD1x/D2x/DAx	322
SAMD5x/E5x	114	SAME7x/S7x/V7x	134	SAMG5x	12
SAML2x	82	STM32C0	19	STM32F0	169
STM32F1	174	STM32F2	71	STM32F3	145
STM32F4	354	STM32F7	181	STM32G0	262
STM32G4	295	STM32H5	70	STM32H7	206
STM32L0	354	STM32L1	180	STM32L4	418
STM32L5	44	STM32U5	174	STM32WB	36
STM32WL	24

TL;DR

git clone https://github.com/modm-io/modm-devices.git
cd modm-devices/tools/generator
# Generate STM32 device data
make generate-stm32
# Generate SAM device data
make generate-sam
# Generate AVR device data
make generate-avr

You need Python3 with lxml, jinja2, deepdiff and CppHeaderParser packages.

pip install lxml jinja2 deepdiff CppHeaderParser

Background

The device data idea originally comes from xpcc, which is the predecessor to modm. Around 2013 we wanted to remove some of the repetitive steps for building a HAL for AVR and STM32 devices and we chose to extract some common data and collapse some peripheral drivers into Jinja2 templates.

This eventually evolved from manually extracted device data to fully generated device data as soon as we found machine readable data sources from vendors. For AVRs, we use the Atmel Target Description Files and for STM32, we use internal data extracted from the CubeMX code generator.

Thus the Device File Generator (DFG) was born. The DFG has been rewritten for modm to make it more maintainable and flexible as well as handling edge cases much better.

We've separated the device data from modm, so that it becomes easier for YOU to use this data for your own purposes. I've written an blog post with all the details.

Data quality

The quality of the resulting device data obviously depend heavily on the quality of the input data. I reluctantly maintain a manual patch list for the bugs I've encountered in the vendor sources, that I don't want to write a fix for in the DFG. I have sent some of these patches to a contact in ST, however, every new release of CubeMX changes a lot of data and can reintroduce some of these bugs. I don't have a contact at Atmel to send bug reports to.

In addition, the CubeMX and AVR data does not contain some very important information, which has to be assembled manually from hundreds of datasheets and is then injected into the DFG. This is extremely labor intensive.

Please be respectful in asking for more data: I do not like spending hours upon hours copying this additional data out of datasheets. It's also much more likely to introduce errors, so automating data extraction is much easier for me to maintain. You may of course open an issue about wrong data, but I'd prefer if you opened a pull request that fixes the problem in the DFG instead.

All fixes MUST BE REPRODUCIBLE by the DFG! This means you need to track down the bug to either the raw vendor data (=> update the manual patches) or in the DFG data pipeline (=> fix the DFG).

DO NOT UNDER ANY CIRCUMSTANCES PUBLISH THE RAW DATA EXTRACTED FROM CUBEMX ANYWHERE! It is subject to ST's copyright and you are not allowed to distribute it!

Data format

I initially wanted to format this data as device trees, however, since it is so tied to the Linux kernel, there isn't (or wasn't) much tool support available at the time (though now there is a Python parser in Zephyr), so we wrote our own tree-based format, which we called "device files" since we're so creative. It allows lossless overlaying of data trees to reduce the amount of duplicate data noise which makes it easier to comprehend as a human.

I do not intend to standardize this format, it may change at any time for any reason. This allows us maximum flexibility in encoding this complicated device information. If you want to engage in format discussions, please consider contributing to the device tree specification instead.

Since I may change this data format to accommodate new data, you should write your own formatter of this data, so that you have much better control over what your tools are expecting! So, if you need this data in the form of a Device Tree, please write your own data converter and maintain it yourself!

For modm we convert this format to a Python dictionary tree, for details see the DeviceFile class in tools/device/modm/device_file.py.

modm-devices's Issues

Add STM32 peripheral RCC enable bit enums

One of the most important thing for any peripheral driver is to be able to enable the root clock for the peripheral. On STM32's this is done via RCC A[H/P]nBENR registers. It would be nice if the database contained an enum like in https://github.com/IntergatedCircuits/STM32_XPD/blob/master/STM32F0_XPD/inc/xpd_rcc.h#L78, where the position consists of a register offset from the lowest A[H/P]nBENR register, and a bit offset within the register. Then the appropriate enum values should be bound to the peripheral instances, allowing a peripheral driver to call a uniform RCC driver API to enable/reset/enable in sleep mode a peripheral.

CI has gotten deprecated

Travis-ci.org is deprecated, and we need to migrate ideally to GitHub Actions.

Add Port multiplexer data to SAM devices

Currently, a typical SAM gpio port looks like this:

<gpio port="A" pin="21">
  <signal driver="eic" name="extint5"/>
  <signal driver="gclk" name="io5"/>
  <signal driver="i2s" name="fs0"/>
  <signal driver="ptc" name="x9"/>
  <signal driver="sercom" instance="3" name="pad3"/>
  <signal driver="sercom" instance="5" name="pad3"/>
  <signal driver="tcc" instance="0" name="wo7"/>
</gpio>

We need to add the peripheral function of the port multiplexer (A-H) to this data, essentially encoding Table 7-1 (PORT Function Multiplexing) from the datasheet. See modm-io/modm#430 for an example where this would have been useful.

http://ww1.microchip.com/downloads/en/DeviceDoc/SAM_D21_DA1_Family_DataSheet_DS40001882F.pdf

SRAM incorrect for stm32g4 series devices

I did some digging to figure out why the modm generated openocd.cfg crashes when flashing my STM32G491 device (with RTT enabled). Turns out it tries to zero out more SRAM than the device actually has!
So I had a look at the device files for this series and found that the SRAM1 size is 112KB

modm-devices/devices/stm32/stm32g4-71_91_a1.xml

Line 77 in 0a6b13d

<memory name="sram1" access="rwx" start="0x20000000" size="114688"/>

The reference manual specifies that all category 3 and 4 devices have 80KB of SRAM1.

The source of the problem is twofold:
First there is a problem with the raw_device_data for this line of devices (STM32G491). The <Ram> section specifies 128KB of total SRAM when it should be 112KB according to the reference manual.
The second problem is that the main_sram is calculated without taking the CCM SRAM into account resulting in more SRAM1 than is actually available.

modm-devices/tools/generator/dfg/stm32/stm.py

Lines 783 to 794 in 0a6b13d

	# Correct RAM size
	main_sram = next( (name for (name, size) in mem_model.items() if size == 0), None )
	if main_sram is not None:
	main_sram_name = next( ram for ram in mem_start.keys() if main_sram.startswith(ram) )
	# compute the size from total ram
	mem_model[main_sram] = total_ram
	main_sram_index = int(main_sram.split("sram")[-1]) if main_sram[-1].isdigit() else 0
	for name, size in mem_model.items():
	mem_index = int(name.split("sram")[-1]) if name[-1].isdigit() else 0
	if name.startswith(main_sram_name) and mem_index != main_sram_index:
	mem_model[main_sram] -= size

This second problem is present for all STM32G4 devices and probably any other that specifies SRAM in this way (ST apparently can't decide on a standard for these things 🤷‍♂️)

I'm unsure if it is intended that the CCM SRAM is counted as part of SRAM1 or if it truly is a problem. In either case, I hope you can clarify.

As an added bonus, I found that the STM32G471 devices are lobbed in with the category 4 devices when it should be in the category 3 devices

modm-devices/tools/generator/dfg/stm32/stm.py

Line 438 in 0a6b13d

'name': ['71', '91', 'a1'],

I can make a PR with whatever changes are required if that is desired :)

STM32U595/5A5/599/5A9 not being generated

It looks like stm.py was set up to ignore STM32U59 and STM32U5A prefixes at some point. We are considering using one of these due to their larger 4M flash sizes and I wanted to view their pinouts in my stm_layout_tk tool, so I updated modm-devices on my system but was surprised to see these ones missing. I eventually found where they were being ignored and removed those lines, but then it errors out about missing memory models for the 599/5A9 series so I put those back on ignore. I also noticed that these are listed as 85C parts and there wasn't an 85C entry in the temperature map.

This is my diff so far:

diff --git a/tools/generator/dfg/stm32/stm.py b/tools/generator/dfg/stm32/stm.py
index 362a04a..00ffb4c 100644
--- a/tools/generator/dfg/stm32/stm.py
+++ b/tools/generator/dfg/stm32/stm.py
@@ -8,8 +8,8 @@ LOGGER = logging.getLogger("dfg.stm.data")

 ignored_devices = \
 [
-    "STM32U59",
-    "STM32U5A",
+    "STM32U599",
+    "STM32U5A9",
     "STM32WL5M",
     "STM32WB1M",
     "STM32WB5M",
diff --git a/tools/generator/dfg/stm32/stm_device_tree.py b/tools/generator/dfg/stm32/stm_device_tree.py
index 7896252..2190680 100644
--- a/tools/generator/dfg/stm32/stm_device_tree.py
+++ b/tools/generator/dfg/stm32/stm_device_tree.py
@@ -26,7 +26,7 @@ class STMDeviceTree:
     """
     rootpath = os.path.join(os.path.dirname(__file__), "..", "..", "raw-device-data", "stm32-devices", "mcu")
     familyFile = XMLReader(os.path.join(rootpath, "families.xml"))
-    TemperatureMap = {0: "6", 105: "7", 125: "3"}
+    TemperatureMap = {0: "6", 85: "6", 105: "7", 125: "3"}

     @staticmethod
     def _format_raw_devices(rawDevices):

I'm not sure why those MCUs were originally put on ignore, so maybe there's some other reason to blacklist them? I can also try and sort out the missing memory models if you like.

Memory data wrong for some H7

The memory map data in the device file generator is wrong for some H7 devices.

Datasheet H723ZG:

Device file:

<memory name="itcm" access="rwx" start="0x00" size="65536"/>
<memory device-size="e" name="flash" access="rx" start="0x8000000" size="524288"/>
<memory device-size="g" name="flash" access="rx" start="0x8000000" size="1048576"/>
<memory name="dtcm" access="rwx" start="0x20000000" size="131072"/>
<memory name="d1_sram" access="rwx" start="0x24000000" size="524288"/>
<memory name="d2_sram1" access="rwx" start="0x30000000" size="131072"/>
<memory name="d2_sram2" access="rwx" start="0x30020000" size="131072"/>
<memory name="d2_sram3" access="rwx" start="0x30040000" size="32768"/>
<memory name="d3_sram" access="rwx" start="0x38000000" size="65536"/>
<memory name="backup" access="rwx" start="0x38800000" size="4096"/>

The data sheet has max. 320 kB AXI SRAM but the device file says 524288. Also our device files probably can't model the memory that is remappable between ITCM and AXI SRAM.

Data Sources for more Platforms

Just for future reference, here are some machine-readable data sources I found over the time:

• Nuvoton NuTool Suite:

  • NuTool PinConfigure: contains JSON files describing package, pinout and signals.
  • NuTool ClockConfigure: contains JSON files describing some of the clock graph and configuration.

• NXP: requires login, unclear data format, something with Java

  • MCUXpresso
  • i.MX Config Tool

Peripheral instances with different feature sets not supported

I'm currently updating the I2C peripheral information. On some controllers (F0, L0) the features of the stm32-extended IP depend on the peripheral instance. I would have expected the DFG to generate multiple <driver> tags for the different instances.

Output:

     <driver name="i2c" type="stm32-extended">
        <feature value="dnf"/>
        <feature device-name="30|70" device-pin="c" value="fmp"/>
        <feature device-name="70" device-pin="r" value="fmp"/>
        <instance value="1"/>
        <instance value="2"/>
     </driver>

Expected:

     <driver name="i2c" type="stm32-extended">
       <feature value="dnf"/>
       <feature value="fmp"/>
       <instance value="1"/>
     </driver>
     <driver name="i2c" type="stm32-extended">
       <feature value="dnf"/>
       <instance value="2"/>
     </driver>

Actions are broken?

Neither the PR event nor the regular scheduled CI Actions is running.

Completely unclear why? Perhaps something was deprecated.

STM32L431 RAM configuration is wrong

This MCU has a total RAM of 64kB, divided into 48kB SRAM1 and 16kB SRAM2. modm configures both of a size of 32kB. Not sure where the error comes from, looking at similar MCU their configuration is fine. Neither I have an idea how to fix that. So I'd ask for help. :-)

Not sure if it would be part of modm-devices as well, maybe the linker script could be updated to include SRAM2 section as well? Switching the MCU to a power savings mode retains SRAM2 only.

STM32F76x devices have wrong memories

Hunting down my issue with memory corruptions I figured out that the XML of the STM32F76x devices have wrong entries for the memories:

      <memory device-size="g" name="flash" access="rx" start="0x8000000" size="1048576"/>
      <memory device-size="i" name="flash" access="rx" start="0x8000000" size="2097152"/>
      <memory name="dtcm" access="rwx" start="0x20000000" size="65536"/>
      <memory name="sram1" access="rwx" start="0x20010000" size="376832"/>
      <memory name="sram2" access="rwx" start="0x2006C000" size="16384"/>
      <memory name="backup" access="rwx" start="0x40024000" size="4096"/>

But the DTCM is actually 128kB, which would shift the addresses of SRAM1/SRAM2 too.

If you could point me to the right location to fix it...

make generate-stm32 fails for stm32l412c8t

./stm_generator.py STM32L4
[INFO] dfg.stm.reader: Found devices for prefix 'STM32L4': STM32L412C8T, STM32L412C8U, STM32L412CBT, STM32L412CBU, STM32L412K8T, STM32L412K8U, STM32L412KBT, STM32L412KBU, STM32L412R8I, STM32L412R8T, STM32L412RBI, STM32L412RBT, STM32L412T8Y, STM32L412TBY, STM32L422CBT, STM32L422CBU, STM32L422KBT, STM32L422KBU, STM32L422RBI, STM32L422RBT, STM32L422TBY, STM32L431CBT, STM32L431CBU, STM32L431CBY, STM32L431CCT, STM32L431CCU, STM32L431CCY, STM32L431KBU, STM32L431KCU, STM32L431RBI, STM32L431RBT, STM32L431RBY, STM32L431RCI, STM32L431RCT, STM32L431RCY, STM32L431VCI, STM32L431VCT, STM32L432KBU, STM32L432KCU, STM32L433CBT, STM32L433CBU, STM32L433CBY, STM32L433CCT, STM32L433CCU, STM32L433CCY, STM32L433RBI, STM32L433RBT, STM32L433RBY, STM32L433RCI, STM32L433RCT, STM32L433RCY, STM32L433VCI, STM32L433VCT, STM32L442KCU, STM32L443CCT, STM32L443CCU, STM32L443CCY, STM32L443RCI, STM32L443RCT, STM32L443RCY, STM32L443VCI, STM32L443VCT, STM32L451CCU, STM32L451CEU, STM32L451RCI, STM32L451RCT, STM32L451RCY, STM32L451REI, STM32L451RET, STM32L451REY, STM32L451VCI, STM32L451VCT, STM32L451VEI, STM32L451VET, STM32L452CCU, STM32L452CEU, STM32L452RCI, STM32L452RCT, STM32L452RCY, STM32L452REI, STM32L452RET, STM32L452REY, STM32L452VCI, STM32L452VCT, STM32L452VEI, STM32L452VET, STM32L462CEU, STM32L462REI, STM32L462RET, STM32L462REY, STM32L462VEI, STM32L462VET, STM32L471QEI, STM32L471QGI, STM32L471RET, STM32L471RGT, STM32L471VET, STM32L471VGT, STM32L471ZET, STM32L471ZGT, STM32L475RCT, STM32L475RET, STM32L475RGT, STM32L475VCT, STM32L475VET, STM32L475VGT, STM32L476JEY, STM32L476JGY, STM32L476MEY, STM32L476MGY, STM32L476QEI, STM32L476QGI, STM32L476RCT, STM32L476RET, STM32L476RGT, STM32L476VCT, STM32L476VET, STM32L476VGT, STM32L476ZET, STM32L476ZGT, STM32L485JCY, STM32L485JEY, STM32L486JGY, STM32L486QGI, STM32L486RGT, STM32L486VGT, STM32L486ZGT, STM32L496AEI, STM32L496AGI, STM32L496QEI, STM32L496QGI, STM32L496RET, STM32L496RGT, STM32L496VET, STM32L496VEY, STM32L496VGT, STM32L496VGY, STM32L496ZET, STM32L496ZGT, STM32L4A6AGI, STM32L4A6QGI, STM32L4A6RGT, STM32L4A6VGT, STM32L4A6VGY, STM32L4A6ZGT, STM32L4R5AGI, STM32L4R5AII, STM32L4R5QGI, STM32L4R5QII, STM32L4R5VGT, STM32L4R5VIT, STM32L4R5ZGT, STM32L4R5ZGY, STM32L4R5ZIT, STM32L4R5ZIY, STM32L4R7AII, STM32L4R7VIT, STM32L4R7ZIT, STM32L4R9AGI, STM32L4R9AII, STM32L4R9VGT, STM32L4R9VIT, STM32L4R9ZGJ, STM32L4R9ZGT, STM32L4R9ZGY, STM32L4R9ZIJ, STM32L4R9ZIT, STM32L4R9ZIY, STM32L4S5AII, STM32L4S5QII, STM32L4S5VIT, STM32L4S5ZIT, STM32L4S5ZIY, STM32L4S7AII, STM32L4S7VIT, STM32L4S7ZIT, STM32L4S9AII, STM32L4S9VIT, STM32L4S9ZIJ, STM32L4S9ZIT, STM32L4S9ZIY
[INFO] dfg.stm.reader: Parsing 'stm32l412c8t'
[ERROR] dfg.stm.data: Memory model not found for device 'stm32l412c8t'
make: *** [generate-stm32] Error 1

git submodule status
 ac6a86c6a81ab316f2e4780c5aa7ab794b9e7fb5 cmsis-header-stm32 (ac6a86c)

Same with cmsis-header-stm32 at master.

DMA instance count wrong for many STM32F1

All STM32F1 of sizes 4, 6, 8 and b which are neither F105 nor F107 don't have a second DMA instance but it is specified as available in the device files. The same is true for F030xC. These don't define the second instance in the device headers. Some of them also specify signals in the device files for the non-existent DMA2.

I found a workaround in the DMA driver for now but it would be nicer if we could fix the device files.

@salkinium

SAM device file inconsistency for MCAN peripheral

The following lines do not describe disjoint device sets, because both match e.g. the same70q19b-an device, which causes errors in lbuild:

modm-devices/devices/sam/same70_s70_v70_v71.xml

Lines 265 to 266 in e093fe8

	<instance device-series="e70|v70|v71" device-pin="n|q" device-flash="19|20" device-variant="b" value="1"/>
	<instance device-series="e70|v71" device-pin="n|q" device-flash="19|20|21" device-variant="a|b" value="1"/>

STM32H7 FDCAN type

In stm32h7-43_53.xml line 209 FDCAN type is stm32-h7, but lbuild not found it.
If I change to stm32, it will be found but the modm FDCAN template driver is not compatible with the STM32H7.

Remapped pins on STM32{F0, G0} are not modelled

Example data sheet (STM32G071) in SYSCFG_CFGR1:

Example data set (STM32G071R(6-8-B)Tx.xml):

<Pin Name="PA11 [PA9]" Position="43" Type="I/O">
	<Signal Name="ADC1_EXTI11"/>
	<Signal Name="COMP1_OUT"/>
	<Signal Name="I2C2_SCL"/>
	<Signal Name="I2S1_MCK"/>
	<Signal Name="SPI1_MISO"/>
	<Signal Name="TIM1_BK2"/>
	<Signal Name="TIM1_CH4"/>
	<Signal Name="USART1_CTS"/>
	<Signal Name="USART1_NSS"/>
	<Signal IOModes="Input,Output,Analog,EXTI" Name="GPIO"/>
</Pin>
<Pin Name="PA9 [PA11]" Position="43" Type="I/O" Variant="PINREMAP">
	<Signal Name="DAC1_EXTI9"/>
	<Signal Name="I2C1_SCL"/>
	<Signal Name="RCC_MCO"/>
	<Signal Name="SPI2_MISO"/>
	<Signal Name="TIM15_BK"/>
	<Signal Name="TIM1_CH2"/>
	<Signal Name="USART1_TX"/>
	<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
</Pin>
<Pin Name="PA12 [PA10]" Position="44" Type="I/O">
	<Signal Name="COMP2_OUT"/>
	<Signal Name="I2C2_SDA"/>
	<Signal Name="I2S1_SD"/>
	<Signal Name="I2S_CKIN"/>
	<Signal Name="SPI1_MOSI"/>
	<Signal Name="TIM1_ETR"/>
	<Signal Name="USART1_CK"/>
	<Signal Name="USART1_DE"/>
	<Signal Name="USART1_RTS"/>
	<Signal IOModes="Input,Output,Analog,EXTI" Name="GPIO"/>
</Pin>
<Pin Name="PA10 [PA12]" Position="44" Type="I/O" Variant="PINREMAP_10_12">
	<Signal Name="I2C1_SDA"/>
	<Signal Name="SPI2_MOSI"/>
	<Signal Name="TIM17_BK"/>
	<Signal Name="TIM1_CH3"/>
	<Signal Name="USART1_RX"/>
	<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
</Pin>

#13 removed the GPIOs of PINREMAP variant completely from the dataset, however, this is not the correct response and requires better data modelling.

Incorrect table for Flash wait-state on STM32L4+ devices

I am playing with a new devkit, the SensorTile.Box which has a STM32L4+ processor in it.

This processor is in modm-devices already so i figured I would make some examples for modm! The default CubeMX project sets the clock to 120MHz, but trying to do that in modm causes a compile time failure. I traced it back to the device XML devices/stm32/stm32l4-r5_r7_r9.xml line 150.

I manually fixed this in my fork, but since I assume this is pulled from cubeMX somehow that doesn't seem like something I should open a PR for (??) The higher clock speed is the main selling point of L4+ so this seems pretty important 😄.

For reference, here is the table(s) from the CubeMX header stm32l4xx_jal_flash.h

           Table 1. HCLK clock frequency for other STM32L4 devices
           +-------------------------------------------------------+
           | Latency         |    HCLK clock frequency (MHz)       |
           |                 |-------------------------------------|
           |                 | voltage range 1  | voltage range 2  |
           |                 |      1.2 V       |     1.0 V        |
           |-----------------|------------------|------------------|
           |0WS(1 CPU cycles)|  0 < HCLK <= 16  |  0 < HCLK <= 6   |
           |-----------------|------------------|------------------|
           |1WS(2 CPU cycles)| 16 < HCLK <= 32  |  6 < HCLK <= 12  |
           |-----------------|------------------|------------------|
           |2WS(3 CPU cycles)| 32 < HCLK <= 48  | 12 < HCLK <= 18  |
           |-----------------|------------------|------------------|
           |3WS(4 CPU cycles)| 48 < HCLK <= 64  | 18 < HCLK <= 26  |
           |-----------------|------------------|------------------|
           |4WS(5 CPU cycles)| 64 < HCLK <= 80  | 18 < HCLK <= 26  |
           +-------------------------------------------------------+

           Table 2. HCLK clock frequency for STM32L4+ devices
           +--------------------------------------------------------+
           | Latency         |     HCLK clock frequency (MHz)       |
           |                 |--------------------------------------|
           |                 |  voltage range 1  | voltage range 2  |
           |                 |       1.2 V       |     1.0 V        |
           |-----------------|-------------------|------------------|
           |0WS(1 CPU cycles)|   0 < HCLK <= 20  |  0 < HCLK <= 8   |
           |-----------------|-------------------|------------------|
           |1WS(2 CPU cycles)|  20 < HCLK <= 40  |  8 < HCLK <= 16  |
           |-----------------|-------------------|------------------|
           |2WS(3 CPU cycles)|  40 < HCLK <= 60  | 16 < HCLK <= 26  |
           |-----------------|-------------------|------------------|
           |3WS(4 CPU cycles)|  60 < HCLK <= 80  | 16 < HCLK <= 26  |
           |-----------------|-------------------|------------------|
           |4WS(5 CPU cycles)|  80 < HCLK <= 100 | 16 < HCLK <= 26  |
           |-----------------|-------------------|------------------|
           |5WS(6 CPU cycles)| 100 < HCLK <= 120 | 16 < HCLK <= 26  |
           +--------------------------------------------------------+

Device Support

Hi, In the modm repository i can see support for nxp devices but i can't find NXP device file generator in this repository.

• Where can i find the NXP device file generator?
• Does modm-devices support ESP32 devices?

STM32G4 Internal temperature sensor has wrong channel mapping

The reference manual p.615 says:

The internal temperature sensor (VTS) is connected to ADC1_INP16 and ADC5_INP4

The adc.hpp file, generated by modm assigns temperature sensor to Channel 17. Similarly, the voltage reference channel is shifted by 1.

class Adc1
{
...
	/// Channels, which can be used with this ADC.
	enum class Channel : uint8_t	// TODO: What is the best type?
	{
		...

		Temperature = 17,
		BatDiv3     = 18,
	};
};

STM32 DMAMUX request mapping data is broken

We are parsing the DMA IP file in the CubeMX data to obtain the mappings between request id and peripherals/signals:
Raw data example:

        <RefParameter Comment="Request number" DefaultValue="" Group="" Name="Request" Type="list" Visible="false">
                <PossibleValue Comment="MEMTOMEM" Value="DMA_REQUEST_MEM2MEM"/>
                <PossibleValue Comment="DMA_GENERATOR0" Value="DMA_REQUEST_GENERATOR0"/>
                <PossibleValue Comment="DMA_GENERATOR1" Value="DMA_REQUEST_GENERATOR1"/>
                <PossibleValue Comment="DMA_GENERATOR2" Value="DMA_REQUEST_GENERATOR2"/>
                <PossibleValue Comment="DMA_GENERATOR3" Value="DMA_REQUEST_GENERATOR3"/>
                <PossibleValue Comment="DMA_GENERATOR4" Value="DMA_REQUEST_GENERATOR4"/>
                <PossibleValue Comment="DMA_GENERATOR5" Value="DMA_REQUEST_GENERATOR5"/>
                <PossibleValue Comment="DMA_GENERATOR6" Value="DMA_REQUEST_GENERATOR6"/>
                <PossibleValue Comment="DMA_GENERATOR7" Value="DMA_REQUEST_GENERATOR7"/>
                <PossibleValue Comment="ADC1" Value="DMA_REQUEST_ADC1"/>
                <PossibleValue Comment="ADC2" Value="DMA_REQUEST_ADC2"/>
                <PossibleValue Comment="TIM1_CH1" Value="DMA_REQUEST_TIM1_CH1"/>
                <PossibleValue Comment="TIM1_CH2" Value="DMA_REQUEST_TIM1_CH2"/>
                <PossibleValue Comment="TIM1_CH3" Value="DMA_REQUEST_TIM1_CH3"/>
[…]

We are making the assumption that the index in the list represents the request index. Thus, the data is assumed to be ordered by request index and must not have gaps with reserved ids. By accident this seems to be true for G4 but not for H7.

The values refer to constants inside the CubeHAL headers. At least there is only one such table per device family. We have to somehow copy the data from the header and use it in the generator for finding the correct mappings.

@salkinium