 Hi and welcome. My name is Rafael Taubinger and this session it's about safety critical applications with IR systems pre-certified tools and ST safety packages for STM-8 and STM-32. The presenters from today's session are Michael Furman, senior field application engineer at IR systems. Roland Helstern, technical marketing engineer at ST. Notice that this session is being recorded and you all are in mute at this point. Please make use of the question panel so we can actually answer your questions on the fly because there is a dedicated team ready to answer all your questions. The agenda from today's session will cover a functional safety introduction, the safety packages for STM-32 and STM-8 MCUs, the pre-certified tools offering static code analysis and coding standards and also some debugging capabilities and finally we will spend some time on actually the practical demo. To finalize we have the summary and the Q&A so we'll have dedicated time to go over your questions. So we will have some pool questions during this session and the best way to warm up or to let's say have an icebreaker, we would like to know you a bit more. So the question is what is your current role? And I will give you 15 to 20 seconds so you can just vote or answer. I think this is always good to get a feeling who is attending our sessions, who is interested in the topic. And I can see that people are still voting, might give another five seconds. People are still joining. Good, so it looks like we have most of people voting already. So I will share here the results and very interesting. We have roughly 75% being developers, either software or hardware architects. Pretty interesting. Good, and now it's time to give the session over to Roland Hellstein. Hello, so now let's start with the functional safety introduction. We will explain the general safety concepts and what ST is offering for safety applications using ST microcontrollers. First, let's have a brief look on safety standards. The IEC 61508 is a meta standard for several functional safety standards which apply to different domains. General concepts and definitions are inherited from IEC 61508. Let's take an example with IEC 62061. This standard is dedicated to machinery applications, but it reuses the IEC 61508 framework, which is a generic standard for designing electrical safety systems. The machinery safety standard defines the scope of application, the risk evaluation criteria, and dedicated safety integrity levels. It includes recommendations for the design, as well as integration and validation phases of a control system for machinery. It is similar to the other standards shown here, dedicated to specific sectors and applications. Let's have a look now on ST offering for functional safety. We have safety packages for STM-8 and STM-32 in combination with built-in hardware safety features. It is a comprehensive set of certified software libraries and documentation to reduce the development efforts, time, and cost to achieve functional safety standard certification. Today, ST offer three functional safety packages. SIL package with STM-32 for industrial applications, plus B package with STM-8 and STM-32 for appliances, and ASIL package with STM-8A for automotive applications. All these functional safety packages are safety certified. One of the latest safety-ready series is SM-32 H7. Let's mention some key points. SM-32 H7 is a large range of high-performance MCUs. The dual core variants on the top embed Codex M7 and Codex M4. There is no lockstep controller integrated, like in a dedicated automotive MCU. However, the dual core allow to distribute safety function on two CPUs to optimize performance of the application. The products come with up to two megabyte flash and 1.4 megabyte RAM embedded. It is available also as a single core with Codex M7 only, and has reduced flash variants, 100 up to 128 kilobyte, for customers who anyway use large external memories. The SM-32 H7 product series benefit from the well-established SM-32 ecosystem. And, as for all SM-32, a 10-year longevity commitment is granted. Now, we take a closer look on the newest variants of SM-32 H7-2 and H7-3 lines. You can see there is extensive peripheral set on all variants, including accelerators for graphic or crypto, analog, and a large number of connectivity. Optional support for extended temperature range up to 125 degree ambient guaranteed operating until 550 megahertz. There is wide choice of packages and pin count from QFN 68 with a small footprint up to BGA or LQFP 176. Now, if you take a product as shown, what is a SEAL functional safety package for SM-32? ST has prepared a complete safety package fully certified, including following. Support for the majority of SM-32 families taking benefits of all built-in safety features inside the MCU. Extensive safety documentation, which includes MCU safety manual with detailed list of safety requirements and examples. FMEA with detailed list of MCU failure modes and related mitigation measures. And FMEDA, a static snapshot reporting failure rates computed at MCU and basic function levels. And surely the package includes the self-test software library for SM-32. The objective of ST solution is to reduce time and cost to build SM-32-based systems certified to IAC 61508 standard. What about the SEAL-2 and SEAL-3 levels for industrial applications? SEAL-2 and SEAL-3 are safety levels inside the IAC 61508 standard. A safety integrity level 2 is achievable with a single SM-32 by observing the requirements included in safety manual, including the execution of self-test library. A safety integrity level 3 is achievable with two SM-32 with the same requirements asked for SEAL-2 case and running in redundancy. The SEAL-32 is a general purpose microcontroller addressing many markets, including industrial and medical applications. In order to offer high level of robustness, we have designed some hardware built-in safety features inside all SM-32 families. For example, all SM-32 series have a dual workshop and a hardware CSE unit. On top of the hardware built-in safety features, we have developed the safety software library. These safety libraries are software-based diagnostic suites designed to detect random hardware failures in SM-32. The latest SM-32 generations embed ECC, error correction code on flash memories. ECC improves the robustness but also helps to reduce the safety time processing. What is a SEAL functional safety package for STM-8? A. This package includes following support for automotive grade mainstream STM-8 AF and the ultra low power STM-8 AL series. It also takes benefit of built-in hardware safety features. It comes with extensive safety documentation, including MCU safety manual, FMEA plus FMEDA, and self-test software library for all STM-8A. The objective of a SEAL solution is to reduce again time and cost to build STM-8A-based systems certified to ISO 26262, ASEAL B-SENET. Now it's time for the next poll question. Yes, so the next question is, are you making use of STM-32 or STM-8 devices? So please vote selecting the right answer. So again, I will give you around 15 to 20 seconds to vote. This is again, of course, an opportunity to get to know exactly what that indies are using or doing most of the time. Good. I might need to give another five seconds. People are still voting. Perfect. And we have a result here. Yes, it looks like there are a lot of STM-32 customers or customers interested in STM-32 or using already a STM-32 that reflects quite the picture or opportunities we see on the market. Okay, let's continue. What is, sorry, the third kind of package ST offers is related to class B. Class B level is often required for home appliances, which need to be certified IC-60-335 and the 6,730 safety standards. ST is offering a complete class B package for STM-32 and STM-8 with certified self-test libraries, optimized code based on SM-32 Q-PAL, the hard-to-abstructural layer, safety manuals, guidelines and examples, and compiler support for SM-32, including IAR, EWR. The class B functional safety package objective is to reduce also time and cost to build SM-32 and SM-8 based systems through household electrical appliance. In this first part of the presentation, we have seen all functional safety packages for STM-8 and STM-32, which are free of charge and fully certified. To summarize, depending on your application, you could select SEAL package for industrial, SM-32 portfolio and X-Cube STL designed for SEAL-2, SEAL-3 applications and certified by Twi-Fleinland. SEAL package for Automotives, STM-8 portfolio and STM-8A SAVE-ASIL designed for ISO 26262 and last but not least, class B package for home appliance. We have solutions both for SM-32 and STM-8 certified by UL and BDE. At a glance, that's the functional safety offer for STM-32 and STM-8. And now, Michael will continue with the part for IR. Thanks, Roland. And then let's continue from the IR system side with our offering for pre-certified tools. And maybe some of you know already or are using already the IR embedded workbench, even in the functional safety edition. And still it might be good to look into the details, what let's say part of the package you will get with the functional safety edition. First of all, it's the certified tool chain, which means it's a special release of the IR embedded workbench that has been certified by Twi-Fleinland for a list of different standards you will see in a few slides. Then there is, let's say, a set of documents part of the functional safety edition, which is of course the safety certificate from Twi-Fleinland. It's the safety report also from Twi-Fleinland with the details about the certification. And then it's the safety guide from IR systems with, let's say, the dos and don'ts, how to install the tool chain, how to set up your project and so on. And I will give a few more details in one of the next slides. Then if it comes to product support, the functional safety edition is offering a prioritized support, which means you can contact our support department whenever you run into an issue with the tool chain. Then from time to time there are validated service packs being rolled out for the functional safety editions, which means it's, let's say, not adding new features or new devices, it's bug fixes for the tool chain and these bug fixes or service packs will be validated from our side. So if you are upgrading or if you are installing the safety pack on an existing installation, then you will get the same set of certification documents. And last but not least, there is a regular send out of reports with known issues on the safety tool chains and I will show you one of the exam or one report as an example on one of the later slides. And if we look at the offering for the devices from ST, we have the functional safety edition of the IR embedded workbench for STM32 or ARM as well as for STM8. Then it's time for the next poll question. Yes, so we want to know what is your functional safety standard of interest? So there are a few options. Please select what applies for you. So we have been talking about the different standards, but of course it's important to get a feeling what is relevant for you. So people are still voting. Again, we extend it a bit longer. So we give the chance that more people can vote and looks like we have a result. Okay, so seems the winner is industrial. So most likely the 6508 and yes, this sort of matches also what we see as requests from the field with the, let's say, majority coming from the industrial area. So if we look, let's say, more into the details or the supported standards of the tool chains, so if you were using the IR embedded workbench for ARM functional safety edition in one of the previous versions, then you had support for the first four standards. So it's the industrial IEC 65008, automotive ISO 26262, the two railway standards and the medical IEC 620304. And this is also the set of standards that we are covering for the STM8 tool chain. And starting with the latest release of the IR embedded workbench for ARM functional safety edition version 8.50.10, which got released earlier this year. We added additional standards. And this is then the four boxes on the right hand side, including agriculture and forestry. Then in terms of machinery control, it's the IEC 62061 that Roland already mentioned. Then we have a standard for process industry and household appliances, which was also mentioned. So if you are working with STM32 and you're going for the latest functional safety edition that is available, then you would have, let's say, the complete lineup of supported standards. And this can help you to reduce your certification time. If we look a little bit more into the details, how the tool chains are being released and maintained from our side. So I picked the example for the embedded workbench for ARM and the major release version 8.x. And around three years ago, there was the standard edition 8.22. And from this standard edition, special release has been created and validated by TÜVSÜD. And this is now, let's say, maintained as embedded workbench for ARM functional safety edition 8.22.3. And it's, let's say, from that point when it is derived from the standard version, it develops independently. Then there were some additional standard releases in between surface pack for the 8.22. And then around one and a half years ago, it was the release of the functional safety edition 8.40.3, a new standard release or a few new standard releases, new surface packs. And then around two months ago, 8.50.10 got released as the latest functional safety edition. So if we look now at the ARM tool chain and the major release 8.x, it's now three functional safety tool chains that are being available and are still being maintained from our side. So if, for example, you started a project with 8.40.3 functional safety, then you can continue to use this version, of course, unless you want to make use, for example, of the additional device support. So all the new SDM32H725 and 35 devices, they were not available back when 8.40 got released, but they are now available with 8.50. So it depends on you and your requirements, if you want or if you have to upgrade. Then I mentioned already that there are reports being sent out with the details about known issues. And here there is a screenshot or part of one of these reports where you have in the first part, it's a unique identifier that is then also being mentioned in the release notes. Once this issue is being fixed, then it's the information what component is being affected. It's a description of the issue. And if available, then there's also a description about a possible workaround. So pretty straightforward. Then I mentioned the safety guide. It covers different aspects related to functional safety project. And as mentioned, it starts with, for example, how to install the tool chain in a proper way, how you could configure your build environment, different considerations regarding coding, library selection, and so on. Here is the table of contents from the latest version of the report that you can get an overview of what topics are being covered. And in total, it's these close to 30 pages, which can give you, let's say, good advice and help you to make educated decisions. Each of these advices has individual numbering. So here, for example, advice 2.6-1 is talking about that you should make sure that third-party libraries are available in a compatible version. And then you can make notes on this advice and you can document your decision with the clear reference to our safety guide. Then let's look at static code analysis, which is, let's say, usually in a close relation to functional safety and what coding standards are being covered by the static code analysis from IAR systems. We are offering the static code analysis called IAR CSTAT. And this is an optional license, which means if you install the embedded workbench, CSTAT is already installed automatically, which means if you make the decision to go for this additional feature, you don't have to modify your existing installation. It's just the additional feature in your license that needs to be activated. It's completely integrated into the embedded workbench, which means the configuration is done in the project options and the usage can be done from the IDE. You can select the rules that should be checked. And once this individual rule selection is done, you can export these settings and import them into a new project. CSTAT can also be executed from the command line, which means if you're going for a continuous integration environment, you could also, for example, have CSTAT being executed from Jenkins. There's quite some documentation available on CSTAT. If I remember right, it's around 1,000 pages. The CSTAT user guide with all the description about the usage and also detailed information about all the different checks. And here you can see a screenshot that was taken from the embedded workbench for ARM with the, let's say, project options window in the background. And then in the foreground, it's the more detailed window about the rule selection, but I will show you later on in the practical session. Then what coding standards and rule sets are being supported by CSTAT. So first of all, it's, let's say, the usual suspects from the MISRA-C spectrum. It's MISRA-C 2004, MISRA-C 2012, and MISRA-C plus plus 2008 are being supported. So you can use CSTAT together with a C or C plus plus based project. And then there are additional checks available around 200 specific to CSTAT itself, then a set of rules and checks related to the recommendations of the CWE, the common weakness and numeration, and then a third set of checks that is covering the SEIS-C coding standard in the 2016 edition. So in total, it's quite a large number of available checks, and you can make use of it to check your code and to get the best possible code quality. Then it's time for the next poll question. Yes. So when it comes to code quality, so it's more like we want to know what code quality, when you talk about MISRA-C, CSTAT-C, common weakness and numeration, what that actually means for you. So if you could please select the option that would fit the best here. And again, a few extra seconds. This is the last poll question here. People are still voting, and I guess now it's time to probably close the session. Yes. And we have a result. Okay. So it's interesting that the majority is, or for the majority of the result, it's a newer, but they would like to learn more about it. Yes. Please feel free, because that's exactly what we as IR Systems and ST are here for. So on the last slide, you will find some contact details. So please feel free to reach out to us. Good. And then the last topic from the presentation, it's about debugging, because the better you can debug your application, the easier it is, or the faster you can reach your requirements in a functional safety context, but of course also for, let's say, a regular application. And the IR Embedded Workbench is supporting for the SDM32 devices, of course, our own debug probe families. So it's the iChat that is supporting JTAG and zero via debug as well as zero by output. It's the ST link that is, for example, also mounted on the evaluation board that I will be using in the demo in a few minutes, which is supporting the same interfaces. And then if you need to use trace, or if you want to use trace, then we would offer the iChat trace family that is supporting ETM trace up to 16-bit wide data interface and up to 350 megahertz. So we have devices with a four-bit interface and up to 150 megahertz, or let's say the superset is then the big probe with 16-bit and 350 megahertz. Then for SDM8, or the IR Embedded Workbench for SDM8, it's the ST link and the STIs that are being supported. In addition, both editions of the tool chain support an integrated instruction level simulator that can be used to get, let's say, especially in the SDM8 world. You can get all the information from the target, from the simulator, even if you wouldn't have access to, for example, trace data in an SDM8 device because the debug interface is not available to collect the list of every instruction that has been executed. Then the debugger supports debugger macros in order to automate sessions. So you can program a debugger marker to set breakpoints, for example, or you can use them to emulate peripherals in the simulator. And last but not least, for the SDM32 H7 device that support multicore, also the IR Embedded Workbench for ARM would support multicore debugging. So you can, let's say, start an instance of the tool chain or the debugger for the master core and then also one instance for the companion core. So you could have a debugging of both cores in parallel. And how this could look like in a debug session. So here is a screenshot that was taken from SDM32AF4-based evaluation board with the trace probe connected. So here it would be the list of every executed instruction in the trace window. Of course, you can monitor what's going on on the stack. You can switch on the timeline that can give you information about the call stack over time, as you can see here, but also power measurement would be available or you can get information what interrupts are happening inside your system. Then you can with the trace probe or the simulator, you can get code coverage based on the instructions. You can see here on the left hand side of the disassembly, the red icon indicates that the first line hasn't been executed yet, but the green icon indicates that these lines of assembly code have been executed. Code coverage would also be available on the function level. It's also instruction profiling being available. So you could see that the block here is executed 16 times and then you can check if this matches your requirements. For example, you have peripheral initialization two times 8-bit and then the overall sum should be 16. Of course, register view is available and then the other usual suspects like memory view, watch window, and so on. So let's say everything that you want to have and need to have in a debug session would be available and the only limitation might be what features are supported by the debug interface that you are using. Then it's time to jump to the demo. So let's switch to the embedded workbench for ARM and as mentioned, I'm using the version 8.50.10, our latest functional safety addition together with the STL provided by ST. And from the project structure, you can see it's similar to what, for example, SDM32 Cubemix would be creating with then two additional source files related to the STL. And together with the two source files, I'm using a pre-built library, which is specified here. And as part of the package, there are two versions of the library. The X1 version is, if I remember right, for all the SDM32 H7 devices with a number on the second digit. And then the X2 version is for the SDM32 H7 with a character, so the 7A and 7B, if I remember right. So for my example, I'm using the 735, so it would be a version X1. Then if I want to run the static analysis, I can go to the project options, and then I can select, for example, that I want to have MISRAC 2012 as a default set. And then I could dive down into the individual rules and select or deselect whatever rule or check I want to have or I need to have. So you would be flexible on that. And if it's then an individual selection, I could export these settings to an XML file and import them for the next project. And if I want to run the analysis, so let's focus on the STL related files, I can simply right click on the group of files and say analyze files. And here in this example, it's five messages being triggered from the first file about the missing external declaration. But when discussing with ST, I learned that there is documentation on these warnings and they have been, let's say accepted, because the compatible declaration would be available in the source files of the library that has been built. And for the second file, it's warnings about using inline assembly code. But if you want to get, well, first of all, there is also the feedback from ST that these warnings have been accepted in the certification process. But if you want to get rid of them, you could, for example, include our intrinsics. And then, for example, the disable interrupt that is being used in the first inline assembly could be replaced by the corresponding intrinsic function. And then the generated assembly code would be identical. And now CSTUD would be fine with this message. And then it would just be two additional inline assemblies. But these also could be replaced by the corresponding intrinsic. So if I build the project, let's close this window, there is one warning being triggered about an inconsistent W chart T size. And this is triggered because this library has been built for compatibility reasons with the version 7.x of the IR embedded workbench. And in 7.x, the W chart T size was 16 bit. In version 8, it's 32 bit. And we have a corresponding tech note on our website that deals with this issue. And when reading through the documentation of the STL, it is stated that the library is not using the W chart T at all, which means then bullet point C would apply that W chart T is not being used. The application works as expected. So the warning can be ignored in this case. So that's the reason why you are seeing the warning. Then let's start a debug session. And I'm downloading the application now to the SDM32 H735 development kit. And in my main function, it's let's say the device initialization in the beginning. And then the set of tests is being launched. So it's in the beginning the configuration of the tests, which tests should be enabled initialization. And then here in line 241, where I have set the breakpoint right now, this function call would then lead into the prebuilt library. So if I run the application up to here and add my struct with all the details to the watch window, you can see that at the moment, all the tests are labeled as not tested. And then if I step over the prebuilt library, then the result will be not tested for the first one because it was defined like that. And the other ones are being passed. And then here it would be, let's say the analysis of the results. And if there would be a failure, depending on the type of error, the onboard LED would either blink fast or slow. Or in my case, hopefully after all tests are passed, I end up with a constant on LED. So if I continue the execution, then I would let's say switch on the LED on my board, which indicates that all tests have been passed. So that's it for let's say a short demonstration on the hardware debugging. Unfortunately, the board doesn't offer a trace interface. So if it comes to let's say more advanced features, I would have to check or I would have to switch to the simulator. And if I start a new session in the simulator, then I have to set a breakpoint for the system clock configuration, because this would fail in the simulator because nobody is setting the lock bit of the PLL. But I can show you what options of debug information you have in the simulator or with a trace interface that would be available from the chip, but unfortunately not from the board. So I could enable trace and switch it on. I can enable the timeline and switch on my call stack, for example. In the disassembly, I can enable instruction profiling as well as code coverage. And let's also use the code coverage on the function level. And then if I trigger a reset, I can already see the startup code being executed. So the last statement that has been recorded is then my jump to main. And if I run the application now until it hits the breakpoint here, you can see that here it's, let's say, the first part of my main function being executed. The code coverage on the function level shows that some functions have already been completely executed. Some partially, some haven't been executed at all. Same picture here in my disassembly. And if I want to get more information, I can zoom in into the timeline. And then if I double-click in my trace data, I can step through everything, let's say, back in time. And if there is a corresponding line of C code in the project available, this will also be highlighted. And you can see when stepping back that also the cursor in the timeline is moving, which means I can directly see at, let's say, what depth of my call stack I am in right now, what execution has been executed, instruction has been executed, what line of assembly code it's coming from and what line of C code it originated. So the full picture either in the simulator or via the ETM trace interface if it's available in the debug probe. So that's it in very short from the debugging point of view. And then it's time to switch back to the presentation and hand over to Raphael again with the summary. Thank you, Michael. And thank you, Roland. So to summarize, before we go into the Q&A, so ST, functional safety packages for STM-8 and STM-32, provide comprehensive certified software libraries, as you saw for ACL-CL class B. So the IR embedded boardbench for ARM and STM-8 is available as a pre-certified tool. A static code analysis can help you to improve and maintain code quality. Also, a very good debugger, the CSpy debugger will of course help you to identify possible issues. And finally, the joint solution from IR systems and ST will remove the barriers and of course reduce the development efforts, time and cost to achieve functional safety standard certifications. Good. Let me have a look here on the questions. And we have the teams here from IR and from ST available. Please, if you have additional questions, make sure to send them in. Okay. I can see one question here. It's about the safety guide. Sorry. Can I get access to the safety guide from the FUSA, the functional safety version? That's probably a question for Michael from IR. Yes. So the safety guide is part of the IR embedded workbench functional safety edition. So it's only available as part of the package and not being provided on an individual basis. So unfortunately, it's only available as part of the package. Thank you. We have another question here. It's about trace and that's probably for the ST team. Is ETM embedded trace macrosel trace available on the STM32H7 MCU? The presenter mentioned that it couldn't be used on the demo. Sorry, the trace couldn't be used on the demo. Maybe Alessandro Paolo, can you confirm that the H7 family supports trace or maybe it was just a board that Michael is using that doesn't have the interface? Yeah, that is indeed correct. I actually got this in the internal chat rather than on the overall questions. Indeed, the STM32H7 MCU is actually perfectly capable of ETM trace. The discovery board used during the demo is not allowing this because this is typically allowed on what we call the eval class boards. So more expensive, more test points, more features, but the board used on the demo is not allowing this. Perfect. Thank you, Paolo. Okay, we are getting some additional questions. There was a question if the functional safety package covers the STM32F1 series and it has been answered here on the question panel. And the answer is yes, the seal package is available for STM32F1 also. There is another question here. So I'm working on a railway project where seal2 is required and we are new in functional safety. Does IRST provide some hand holding in such cases? So maybe it's a mixed answer from above side. I don't know, Michael, if you want to start commenting a bit on what we can provide from IRST and then from ST, what kind of assistance or help it's provided when it comes to functional safety projects. So if I should start from IRST side, we are providing, let's say, the tool chain with all the documentation. We might be able to give you some advice, but let's say if it then comes to the detail of the application and the certification of the application, this is a little bit out of our scope. But depending on the area or the country and region you're coming from, we might know certain parties that have their focus on the development or, let's say, guidance of functional safety project. So if you can reach out to us at fae.ir.com, then we can check what certain parties that can support you with the functional safety project might be available in your region. And what concerns ST? So the usual support is we are our micro support team. So in case questions related to our library, this is handled by our micro support team and supported, yes. Perfect. Thank you, Michael. Thank you, Roland. Yeah. And we have another question here that it's actually related to the ST functional safety packages. So what are the contents of the software library? So the content is for sure a set of documentation, so the safety manual, then the FMEA, FMEDA and the library itself, which is provided under NDA in binary format and certified by just right now. Thank you, Roland. Yeah. And I might have another question here for IR for Michael. Right now I'm using ARM functional safety embedded workbench 8.22.3. How to upgrade to the latest version? So if it comes to, let's say, upgrading the project, then it would mainly be open the project with a new version and check the release notes of the new version if some modifications on the code base are required due to some upgrades. If it comes to upgrading from the license point of view, then we are, let's say, the embedded workbench functional safety additions are individual products for every version, which means you have a license for 8.22.3, which means this license is for that version only. If you want to upgrade, you would have to contact our sales colleagues and then this existing license could be transferred to a newer version so that you can use the later version, but this transfer of the license would mean that you would lose your functionality for 8.22.3. So yes, it's possible to upgrade to a later version, but this means then that you would lose your initial version. So it's sort of a point of no return, more or less. It's only the license for one specific version of the embedded workbench. Rafael, I want to come back to the previous question I answered to the whole package, but the question was more specific to the software library and here the content of the software library is there is a bunch of implemented routines dealing with the tests for the core, test routines for the flash and test routines for the RAM to be more specific on this point. Very good. Thank you, Roland. That was probably when I was reading the question. Perfect. Very good that you catch that. Good. I can see that we are still getting some additional questions here and let me just go over here. Some of them have been answered it now verbally. And as always, if you have some questions after the session, you are welcome to reach out to us. We will be able to help you. And I can see that most of the questions have been answered here. Maybe one that can be shared with the team is the ST-Link version 3 support ETM trace. Yes, I can probably pick it up all again. The ST-Link is expected to be a sort of an inexpensive probe for STM32 development. So we are actually not intended to support ETM trace on that probe. However, there are plenty of proprietary probes including IRs which are actually ETM compatible and that can be used for debugging boards which have ETM signals. Wonderful. Thank you, Paolo. Good. Very good. So we are coming close to the end of this session. And again, if you have any further questions, you are always welcome to reach out to us. And I will thank you for your time and all the time you spent with us and the good questions. Thank you so much.