modm-io / modm-devices Goto Github PK
View Code? Open in Web Editor NEWCurated device data for all AVR and ARM Cortex-M devices
Home Page: https://blog.salkinium.com/modm-devices
License: Mozilla Public License 2.0
Curated device data for all AVR and ARM Cortex-M devices
Home Page: https://blog.salkinium.com/modm-devices
License: Mozilla Public License 2.0
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
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
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
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
I can make a PR with whatever changes are required if that is desired :)
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.
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.
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...
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.
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>
Neither the PR event nor the regular scheduled CI Actions is running.
Completely unclear why? Perhaps something was deprecated.
The memory map data in the device file generator is wrong for some H7 devices.
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.
Hi, In the modm repository i can see support for nxp devices but i can't find NXP device file generator in this repository.
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
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.
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 |
+--------------------------------------------------------+
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.
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,
};
};
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.
Just for future reference, here are some machine-readable data sources I found over the time:
NXP: requires login, unclear data format, something with Java
Travis-ci.org is deprecated, and we need to migrate ideally to GitHub Actions.
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.
./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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.