 Ok, salut tout le monde, merci d'être ici. Mon nom est Erwin Goryu, je travaille pour STA Microelectronics en Le Mans, en France. Et je vais... Le but de ce talk est de vous donner des informations si vous voulez commencer en utilisant Zephyr STM32. Je vais parler de moi-même. J'ai commencé à travailler en Zephyr en 2016, quelques mois après le projet qui a été créé. Ok, je suis désolé pour ça. J'ai travaillé en MBD avant, mais c'était ma première étape en projet d'open source. Je contribuais à l'inheurale, j'étais un employé de microelectronics STM, mais j'étais partie de l'inheurale. J'ai contribué à l'introduction de devices. Je suis STM32 en chilmanturale. Dans ST, je suis leader technique Zephyr. Vous pouvez me trouver sur le github ou la discord. C'est tout pour moi-même. Pourquoi proposer ce talk? J'ai été involved en Zephyr, active en discord et github. J'ai usually answered the same questions that came from people that want to start their project on STM32 en Zephyr. When questions are general to Zephyr, general information can be found quite easily inside Zephyr documentation, at least when you want to start. But for vendors, there are some specifics. There is a common porting solution, which is device-free and common APIs. But there are still some specifics to each vendor. Frequently, people can be stopped for whatever reason. Aim of this talk is to answer most of these questions if you want to start on STM32. Eventually, I hope that we'll find a solution to document this properly inside Zephyr documentation. What I hope you learn from this talk is what are STM32 resources, documentation and so on, that you will be able to use inside Zephyr. What is the coverage of STM32 part support? And then some information about how to configure stuff on a status on some particular subsystem. OK, so a bit of an overview about STM32 support in Zephyr. So whatever I will present today is really the result of a community contribution. I've made a bit of statistics when preparing this talk. I found that there were nearly 400 contributors that issued more than 5,000 commits on a piece of code related to STM32. Could it be boards, device-free, drivers? There are more than 130 boards supported, more than 180 SOC supported across 19 STM32 series, more than 40 peripherals supported on a wide range of features. So could it be a trusted firmware, USB, Ethernet, CAN, BLE, Java, and so on. So about the resources. So there are two sides of these questions. Using Zephyr, you'll be able, on STM32, you'll be able to benefit from the tools that are available for all the SOC vendors. So NGDB, OpenOCD, you'll benefit from device-free. Using STM32, you will benefit as well from the STM32Cube ecosystem. So we are using the STM32Cube packages to implement the drivers. This one I'm using is not directly linked to implementation and so on, but this is the MCU finder, which is perfect if you want to find documentation, data sheets for any part or board. It's quite powerful database. You can use the STM32Cube programmer to flash, STM32Cube ID to debug. So this requires a particular setup, but it works. And you can use the STM32Cube monitor tools for monitoring, for instance, for power and so on on your device. So about Qube HL and Qube packages, we are integrating them. So for each STM32 series, we are collecting a fork of the official Qube package inside HL and STM32 module. So these packages are updated once per the shared release. And so these are forks and we are technically forks because there are several Git projects to one Git project, but Git repo to one Git repo, so it's possible to maintain some fixes on top of the Qube packages so that for instance there is some incompatibility with Zephyr or bug identified that we know that will be released in the next Qube package we can temporarily maintain a fix. So we are able to progress on Zephyr and not being blocked by delivery that will come later by the official STM32Cube packages. And then STM32Cube APIs are used for Zephyr driver development on STM32 parts. So this allows the reuse of a validated code on mature code and it allows also factorization. So for instance we'll have on this is mostly what the case for all drivers but there will be only one driver that will support all STM32 series so there is one UART STM32 driver that works across all the STM32 family and the same for a lot of drivers like DC, ADC and so on. So we are using HL, LL or CMSIS files depending on driver specifics so if you are not familiar with this terminology HL provides high level abstraction on the STM32 peripherals so it's quite powerful full feature it is quite useful to develop complex drivers like Internet, USB and kind of drivers that are complex to implement and require a lot of stacks and so on. But we can also use LL API which is a low level API so low level because it's very register abstraction and that allows to to benefit from low footprint and this is quite flexible to implement it allows a good impedance matching with the API and it allows to develop it's quite useful to develop simple drivers like UART I2C, DC and so on. Yes, few additional words about while I'm on the HL topics there are as well CMSIS files that are available in this module and here is an example of what I call a CMSIS file and this is the SOC description in C header and inside this header you'll find a lot of information or the complete information the complete description about the part and this is generally helpful when you need to to populate device entries like IRQ number register base address and so on. Sometimes it can happen that Zephyr API does not support the features that you would need from the from the hardware block but this this functionality is available from the HL you can totally in your application mix Zephyr on S32 cube API and so this requires specific setup but this is described at the address which is there. And last word about the HL is that there are asserts in S32 cube HL and there is a way to enable them with this particular config setting it can be useful for debugging ok so now we enter the we put then really on the technical things so the idea is how to setup a new a new board that would be using S32 component in Zephyr so this is a good way to start so the first so the first step is to so this will be mostly advisory so the first step is to include the DTSI for the S32 part you will be using so for instance here we are using a board which is based on S32 H7B3 DTSI so it's not always easy to find your ways around this nomenclature so in the SOC datasheet you will find an explanation in the end of the datasheet about the nomenclature so first you will get the name of the series so this part is easy then you will get the SOC variant so the next the next letter after the SOC variant is a pin count so in this particular piece of information we don't use it when giving name to the SOC DTSI file and we are using a X to state that we are not using it and the last bit the last letter is the SOC package memory size which is high in this case and that is generated 2 megabytes so so if you want to use such part in the folder DTSI STH7 you will need to look for STM32 H7B3 X, Y, DTSI so you find the part, great if you did not find the part that you are looking for don't panic there are solutions so maybe the part that you want to use is a memory size variant this is the exact same part but with a different flash size so in that case you can just add a new file and provide a new for the flash node state a new size which is matching the part that you want to use so in this particular example this would be one megabyte flash variant and we are just adding a new DTSI file which will be XJ instead of XI and we are stating that the flash size is one megabyte so this is the easiest issue that you can make then maybe you are using a different part which is not actually supported not yet supported so there are two ways so either you are finding some part which is quite close from the one that you want to use so to do that what you can do is to check the data sheet compare the CMC files to see what are the differences what is available in the file on the part that you want to use so either you find a description of something that is exactly matching your need and you can use it directly so either you need some adaptation like for instance here we can see that the H7B3 is a variant of the H7A3 plus crypto so we are just including the H7A3 and we add the crypto node and this is how we are building the whole device 3 for SEM32 parts so this is relatively easy to add and to add the node for a new peripheral in general what is working for the cases is to seek for this node in series that are close or compatible with the series you are using so once you have included the right part the next step is to configure clocks so how to proceed so there are four steps so you might be familiar with this but so what you will need to configure is first to configure the fixed clock like high speed internal or external either configurable clocks or low speed clocks then you will need to maybe you will want to use a PLL so you will have to configure the PLL and then configure the source clock for the core and finally configure the peripheral speeds normally if you are doing this should be things should work afterwards so this is the theory and technically we are doing this using device 3 for SEM32 parts so for instance here what we are doing is that we are enabling the HSI48 we are enabling the HSI so high speed external clock with the clock frequency that is 24 MHz we are configuring the PLL so PLL will take HSI as input you have to configure the divisor, multipliers the press carers for each clock output or at least the one that you care you can configure another PLL and finally within the RCC node you have to configure the core so here we are configuring the core source clock as the PLL so in this case this will be the output output P of the PLL you need to configure the clock frequency and configure the press carers for each bus that will be used so if you need help on this part so you can look at the reference manual in general this is well explained what are the capabilities if you don't manage using the reference manual you can use QBMX which is another part of the STM32Q ecosystem tools and that has a way to generate valid clock configuration so this is a useful generate ok so now that we have configured the clocks maybe we need to configure the peripherals that will be used for the applications so what I would like to answer is how to know how to identify what are the peripherals that are supported what are the configurations that are supported for this peripherals and how to configure the usual settings for this peripherals so what are the supported peripherals so once again you'll find the answer inside device 3 device 3 is the main reference for a lot of things so you need to find your DTSI file and look at the nodes that are inside this file and follow the inclusion scheme and you'll have the overview all the peripherals that are supported if there is one instance of order block which is missing like for instance you need to use the USART 6 and this one is missing there are all the other USARTs on your art that are available so you just need to add the missing node on populate its properties so once again the CMC files that I mentioned earlier to get the base address the clock configuration and the interrupt number so generally this is the only thing that you need to do and if there is a missing device once again you need to check if there is a similar device available in a series which is compatible and then on the peripheral I'm interested to know what are the possible available configurations like for instance if there are flow controls that I can enable or pre-configure using device free are there pre-scalars that I can set so actually what we want to know if it is supported by the driver answer is once again inside device free there is a fair documentation there's a quite useful page which is the binding index where you'll find pervender all the compatibles that are supported within the fair and so you need to look for the compatible that you are interested in and you'll see what are all the properties that are available and you can configure for your hardware block so now we are getting to the common property settings that you need to configure to set up your peripheral so let's say we want to use usart1 console so we need to enable usart node so I will not go into device free details but just need to put status equal ok but then what we want to do is to configure the pin configuration for this device so you need to populate the pin control zero property what we are providing to ease this step is we are providing pin control.dtsi files and this is usually tricky part is that these files are not within the fair folder they are within the fair repo they are available inside hl stm32 repo we are generating these files for each stm32 part so technically if the part is available you will find the files that match your part and the file is supposed to be complete for all the supported peripherals so you will find a configuration for your pin for all the pins that are available on the part and for all the possible configurations so we are generating this from a database which is provided by stm32 and which is the same database that is used in kubemix so should theoretically be complete and have the correct information one trick is that for some for some pin configuration nodes so aside from the basic pin configuration so for instance here we are stating that for usart1 takes to set it on p9 so it can be maybe written to small but we are stating that it's using GPIOA, pin9 and internet function 7 so this is basically what is required to configure a pin and additionally for some specific pin configuration we are as well providing some property which is generally fitting the purpose of the pin like for instance for usart takes we are setting a pull up so we are adding the pull up property systematically for all these usart takes nodes in general this should fit most of the applications but if for specific reasons your board doesn't match this pre-configured setting you just need to update the node in your board DTS file delete the property and add the property that is fitting your configuration like a pull down in this case even if it might not make sense ok one common issue in when using these files is that if there is some configuration issue within your manifest you'll get this around stating that when compiling the device 3 the file is not found so in general waste update command will solve the issue in most of the cases so if you find this error just run waste update this is also valid for a lot of other issues but this works well in this case if you are interested in using microcontroller output you can use also pin control properties so this requires some it's not fully implemented yet but it's easy to enable within your application so there is an issue where all the steps required to do that are explained should not be a major issue so next settings that you might want to use in your application is DMA a bit tricky recognize that so you need to add to enable DMA you will need to add DMA property providing DMA names enable the DMA devices and provide the correct configuration in the DMA properties I agree this could be tricky this should be correctly explained in the binding section so you just need to find what is the DMA that is need to use to be used by your device and look at the bindings and there is an explanation on how to configure it how to find the information from the reference manual and configure it properly I hope that in medium term we will be able to provide a pre-configuration on DMA you will not have to do that in your board configuration and eventually I hope that we will be able to just say DMA enabled as a property and it will be available on the last part which is something relatively recent is the support of domain clock so what is domain clock so it's used to support some specific cases like if you need a 48 MHz clock to schedule your hardware like for USB for instance if you need to select or you need for power management to have a clock which is persistent in stop mode so there is a way to configure specific mux to state what will be the domain clock for my device so this is something that we can see in kubemix so this looks like this so for my start one I can select a variety of sources and this is a way you need to do it in device 3 so you just need to copy the initial clock configuration that you find in the DTI file and add on top of this the configuration that you want to use so for instance here I'm configuring the domain clock as a HSI so I know that if I enter the stop mode HSI will still be present then I'm using this second property that will state the values that you're finding in the reference manual to know those values that has to be configured in the register you can find this in reference manual in the reset and clock controller section and so of course we should not forget to enable the HSI clock we are talking about power management so what is power management status so the power management is made available per series basis so it differs from the driver implementation each reach in which generally whatever feature you want to support once it's supported in the driver it's generally available for all the series and it's not the case for power management where it's implemented so far per series so you need to check the code so for my specific series in the stock top folder what are the modes that are implemented so this should be implemented for all the series that are low power ones like LX series and so on for the series that are high performance like F4 F7 and so on it is not supported so yes you'll see what are the states supported I will not turn the details about how to configure the stop mode so this is already this is documented in Zephyr documentation because this is quite these are Zephyr common bindings so this is properly documented just one thing that you need to know is that if you want to enable power management so using config.pm by enabling config.pm what you need to do additionally is to enable a kernel tick source that will remain available when the core clock is gated so usually the kernel tick source is a cortexistic but when we enter power management modes like stop zero starting from state zero the cistic will stop and the kernel is losing hisistic source which is a problem when you want to wake up so for STM32 what we are using is we are using LP team which is a low power timer and that will work in these low power modes and that is used as the kernel tick source when doing power management so once again you need to configure it in device 3 and this should work also note that if you want to make some so this is not in the documentation but this is generally useful there are some power management samples that works on STM32 that are available inside samples, boards, STM32 power management and these are dedicated to STM32 and can help to test specific configurations so this is in power management in Zephyr there are various levels and then there are PM device power management level this power management level has to be implemented device per device and so you need to look at the code to see on which device it is implemented so for now it is a GPIO UART I2C and so you will find once again you will find in the samples you will find examples of configuration I will not go into the details because I am a bit late I have much more time left so I will speed up a bit one point about Trusted Firmware M so if you are interested in Trusted Firmware M basically you should know how it works an important thing to know about STM32 configuration is that Trusted Firmware basically the non-secure side will run it will be run by the TFM and the global partitioning of the platform is also done by Trusted Firmware and you need to match your board flash partition to the partition which is configured by Trusted Firmware and the source file to find what is the actual flash layout that you are supposed to do is available in TFM it is not easy to find for each platform that supports TFM you will find a flash layout and your application has to match the partition which is done by TFM so I provided an example of the mapping that you need to do between the partition done in Trusted Firmware and the usual partitions that we are doing in Zephyr ok, the next step on STM32 subsystem so we need to extend the power management support and complete it will work as well on supporting XIP on external memories not there yet we are starting working on it we will try to stick as usual with Zephyr Evolution like USB, DMA and so on keep an eye on the backlog so I am done with things that I wanted to share don't hesitate to jump in so ask questions if you need an STM32 channel in Discord don't hesitate to contribute your features and fixes so we are welcoming any changes, features, additions and fixes don't hesitate to watch the areas that you care about in GitHub if you are using if you are a heavy user of ADC watch the changes that are made because there are a lot of pull requests that are made by the community so we are on a level of 50 pull requests that are done per month an STM32 area drivers so there is a lot of work so it can sometimes happen that we are merging stuff that maybe should not have been merged but we are trying to test everything but sometimes you guys may have better test setup and have better applications than we have to test every changes so don't hesitate to watch the areas that you care about to review, to help us and review and that's it for me so I don't know if we have time for questions we probably do thank you very much there is a couple questions in the live chat and then 1 ou 2 questions generating the device 3 for parts or parts of it could be done maybe from a QBMX project is this something that you have considered or that we might see in the future so the question is yes did we consider to use a QBMX to generate device for stuff so this won't happen soon if this would happen one day I will love it but this is not in QBMX plan for now you introduced a public statement that Azure Arto will be the main operating system used for SGS microcontrollers in the future I mean in my company we are a user of SGS products ourselves and I wanted to ask why are we now having yet another operating system in the ecosystem when you mean Zephyr yes, why is there now also support for Zephyr originally the statement was that from the U5 on board there will only be Azure Arto going to the future well this is the question why we are adding support on SM32 U5 on Zephyr well this is open source project so we did it actually but if I have not done it anyone from the community could have done it and if it was done properly I would have merged it with pleasure as it happened on C0 recently thank you and so yes this is open source you cannot block things this is a community work alright and I think we are running out of time thank you again everyone ok thank you