FreeRTOS and SEGGER Tools Webinar - Q&A

[#1]

General Questions

Q: Richard Barry, what inspired you to develop FreeRTOS? What is next for you and FreeRTOS?

[Richard Barry] Well I will start with the abbreviated version. Back then I was playing around with things like DOS. If you remember Ms DOS and DOS extenders? I was getting really close to the hardware and I thought it would be fun to create something like this. I got it running on little 8-bit devices and also x86.

The longer story is what really gave me the motivation to actually do it properly. Some time ago, I was asked to recommend a new operating system, a real time operating system.

So when I'm talking about operating systems now, I'm not talking about rich operating systems like most people would, and I'm really talking about schedulers and executives. I think would be a more accurate term. And I looked around for an open source version, the open source landscape was very, very different. Back then, I think people recognize that it's not like today at all. I looked for open source versions and they all had reasons why I wouldn't use them. It wasn't clear who owned the IP or it wasn't clear that anyone would ever support you. Or the code quality was not what I hoped. So after all that, I thought there must be thousands of people that have gone through this looking for something. And with my geek tendencies, I thought I'd create one myself. So there was never this grand plan and what have you, but I think it was proven right that there were lots of people looking for it and then my life just got consumed by it.

Q: When would you suggest the use of FreeRTOS over Bare metal C Program?  

The use of any RTOS is generally motivated by productivity. Factors to consider include: multitasking, communications stacks, application portability, system-level debug, and resource efficiency. The introduction to the free to download FreeRTOS book covers this a bit at https://www.freertos.org/Documentation/RTOS_book.html

Q: Where can I find out more information about what FreeRTOS is and how to learn more about it?      

You can start with the free to download FreeRTOS book at https://www.freertos.org/Documentation/RTOS_book.html and the other documentation found on freertos.org. There are also many Youtube videos available if you search for "FreeRTOS"

Q: What's the memory footprint of FreeRTOS?

The answer depends on your application.  There is helpful information and estimates found here: https://freertos.org/FAQMem.html

Q: Is FreeRTOS derived from or related to TICKS RTOS?

No, FreeRTOS is not related to any other RTOS. 

Q: Is there a working FAT module for SD cards?                

The FAT module is quite mature and, as far as can be quantified, robust.  It is still considered a "labs" project because it has not gone through the security review necessary to make it a formal release.

Q: What is the status of power fail safe FLASH filesystems for FreeRTOS?

This is not something we provide ourselves, but I believe Arm have FreeRTOS integrations with their open source file system, and we have examples that use products.

Q: Is future work on the MPU port ongoing or planned? What about for subregions?    

That is on our roadmap. The plan is to first make the existing scheme simpler before adding subregion support though.

Q: Has any thought been given to providing C++ wrappers for RTOS/driver functionality?           

Now we do all our testing in in C rather than C++. But you should find that you can compile the brioche code in a C application because it's got the extern C. You know, uh, taxed in there in the header files. So if you compile free auto size C and the rest of your application as C++, then everything should work. And there are lots and lots of people there that do that now.

Extensions from that there are people who provide C wrappers for pre-orders as kind of like third party components. But there's one who is very, very active on our support forums that. And provides, you know, some FreeRTOS C++ code. We don't say we don't develop that ourselves, we should make it more obvious. I think maybe having some examples on the free answers website which are using those. Those wrappers would be good. But yes, there are various options for C++ out there, but they tend to be third party and we kind of encourage that as well.

Q: Could you expand on what Memory Safety Proof covers?

See https://www.freertos.org/2020/02/ensuring-the-memory-safety-of-freertos-part-1.html

Q: What was the security module used on the EVK to do the provision?

The security module was not required by the demo, however, the daughterboard is the "EdgeLock SE050 Development Kit".  You can find details here: https://www.nxp.com/products/security-and-authentication/authentication/edgelock-se050-development-k...

Q: Why are static FreeRTOS APIs preferred over the Dynamic Heap Libraries applications?         

Safety related applications normally require static allocation.

Q: Is FreeRTOS reliable for a continuous operation (years) without rebooting? 

As far as I am aware the only time dependency is on tick count overflows - and FreeRTOS handles those internally (transparent to the application using FreeRTOS).

Q: How many external dependency FreeRTOS codebase has, do you see any potential security problems here?

So there's two things here is having contributors and security there, and the other is External dependencies, as far as libraries are concerned. So FreeRTOS itself does not have any external dependencies, but if you integrate it into an application again, I don't want to be too IoT specific, but let's particularly in IoT where you are wanting to have  crypto and TLS with transport layer security just so the transport layer security is the same protocol that you use every time you use your web server to an HTTPS, right?

So that's authenticating and make. Making sure that your connection is secure. And there is, well again, you can use any TLS you like in our reference integrations. We tend to use either WolfSSL or mbedTLS. The mbedTLS is the LTS version, so you should get security patches. Fallout as well. And generally we would use our own TCP IP stacks. There are lots and lots of people use FreeRTOS with lightweight IP as well.

And as far as people contribute, as far as external dependencies go, I think that's about it all, or that at least that's the major one. As far as contributing code goes then, every release goes through testing and our showed that table of the release criteria. A lot of that is designed to minimize the risk of introducing something introducing a security problem, the memory safety proofs in in particular, and we also have this. What we call the pull request bar raising program where senior engineers have to give a sign off to anything that's coming into the codebase and we have, I suppose, less security related, but we have now maybe 20 different boards in the lab. Where everything is compiled and tested every night plus all the checks that run every time you check code in so  there's no guarantees of anything obviously, but I think we go a long way to try and prevent these things.

Q: What platforms do you see used the most with FreeRTOS?   

The 32-bit Cortex-M space is the huge majority, especially in real production use cases. We don't see much 8-bit usage anymore and there is growing 64-bit usage as well as growing Cortex-A usage. Ultimately FreeRTOS just goes wherever the Community takes it. 

Q: What is the most non-easy, but wanted feature, which you are working with at the moment preparing new FreeRTOS releases?       

Gosh well I think. Maybe this is a bit, maybe my answer is going to be a bit specific to IoT, but there over the last few years as I've just I yeah as I've described, hopefully we've simplified using and simplified integrating libraries and, but they  you still you still see Cage. You still have to build it.

We have a product which was launched and in preview actually, so it's not giving anything away called Express link. Where a lot of those libraries are integrated and provided for you. Actually as a connectivity module, so you can  really simplifies that interface for you. It's all pre provisioned as well, but the second thing is I think as people  developing their products and hopefully it gets simpler and more straightforward as time goes on.

The next the next challenge is people come up with how to do that at huge scale. So it kind of goes a little bit outside the operating system per say. But how do you if I'm if I'm going to market with five devices, it's easy if I'm going down going to market with 500,000 devices then how do I do that?

So that is one of the areas where we try and focus and Amazon have many different ways of provisioning things that at huge scale. And trying to simplify that for the device developer as well who maybe doesn't know anything about, cloud technology and that kind of thing, so I think that's the challenges we see now are actually how we do things at a huge scale.

Q: Is FreeRTOS really free (at least for engineers), are there any potential problems with licensing?

FreeRTOS is open source, released under the MIT open source license, so yes it's really free and can be used for any purpose under the terms of that liberal license.

Q: What can be your recommendation to speed up the compilation process?    

The same as for any other C project really - ensure to use all the cores available to you to build multiple files at once, and build libraries that rarely change to .a files and just link to them rather than build them each time you do a clean build.

Q: Do you recommend using more than one blocking RTOS call in the task while(1) loop?

It really depends on what you're trying to do. But yes it can be quite normal to use more than one more than one blocking call. For example if you're triggering on an analog conversion and waiting for that to finish. Or any other action that you might wait to finish and want to let another task run.

Q: Is there any rule of thumb for choosing the optimal tick period versus the microcontroller clock speed or is it based on something else?          

It is based on the needs of the application, not the microcontroller.  The tick period sets the granularity of timing you can achieve.  For example, you can't block for 2ms if the tick interval is 100ms.

Q: Is that possible to get FreeRTOS tick count in microseconds?

It is possible, but not advisable, as you will spend a long time in the tick interrupts.  If you need microsecond accuracy use a hardware timer.

Q: How much "free stack" can be considered safe for a thread? Let's say that I assign 1KB of stack to one thread and this uses up to 800 bytes, is it a good thing to have 200 bytes of free stack? Or is it too tiny?

If you know the maximum stack usage of any task, then the stack need be no larger than that.  However calculating the maximum stack usage is not always straightforward (although I think GCC will tell you) so I like to leave a buffer beyond that of about 20 words at least.

Q: Why keep semaphores and mutexes instead of task notification and event groups or simple Boolean flags? 

They all have different use cases.  For example, you can have multiple tasks blocked to send or receive on a queue (in priority order) which requires a lot of logic, whereas a direct to task notification goes directly to the target task, which requires a lot less logic so is faster.

Q: Programming for audio usually requires getting into the system audio interrupts, and often requires modifying system classes. Real time processing is also a concern. How easy is to get into the audio functions and buffers to do some audio processing real time.

One of the main authors of our TCP/IP stack does audio processing.  If necessary you can set the priority of the interrupts above the priority of the interrupt mask used in RTOS critical sections, so nothing FreeRTOS does can delay audio processing.

Q: If I have an IRQ executed at high frequency, can I isolate it from FreeRTOS and execute it outside of RTOS, in order to avoid the delays associated with the context saving and loading. Everything else would be executed inside of RTOS!             

The answer is yes. And this is something that that does come up with customers depending I'm going to use cases the key thing is just not making sure not to affect other RTOS components. Like you know mutex or semaphore or something like that. And really seeing that inside of this outside of the RTOS because that can cause some issues. But for basic C code that you want to execute in your in your key and that's absolutely fine. The trick is to make sure that the configuration of the system leaves the priority of the interrupt. Your you know the very fast interrupt above whatever is masked by the operating system, so the operating system does not disable interrupts totally. The only masks up to a certain priority level. If you have anything above that, then nothing the operating system is doing is going to delay those interrupts coming in.

And then if you want to do processing, you know if you've got a peripheral which is moving data and you want to process it within a task. Again, make sure that's make sure that's a high priority task. You can use things like direct task notifications. That's the fastest way to get from the interrupt to the task. And you can just have a RAM buffer or a circular buffer or FreeRTOS has a thing called stream buffers.  You have to be a bit careful if you're all using interrupt properties which are above those which are masked by the operating system, then generally you can't use the free Artist API calls from within that interrupt, but one main use case is actually audio streaming.

Q: How do you suggest handling different MCU power modes in a multitasking system where tasks utilize different hardware resources?  Should power switching be handled by the idle task handle?        

The tasks can determine that themselves as they know when they need different peripherals.  Also have a look at tickless idle mode in FreeRTOS - that has pre and post sleep macros you can use to turn off parts of the system before entering a low power state, and then turn them back on again when the system wakes.

Q: Can I develop with FreeRTOS on a Windows or Linux host device so firmware developers can start developing without the need for hardware?

Absolutely, and we I would almost recommend that you do that so server runs in windows and it runs on Linux as well, so they're so they're the scheduler is running and the scheduler manages the windows threat. Context switching is done by Windows or Linux, so when you when you create a thread, what it actually does is spawn a windows or a Linux task. Of course on Windows and Linux you do not get the real time behavior.

And also there's QMU that we use a lot and come if you want to use the real compiler, the real cross compiler. Then we use QMU to do a lot of testing as well. In fact, most of the TCP IP stack, for example, is actually developed in under Windows. Getting raw access to the to the Ethernet using winpcap. Because it's such a hugely rich development environment. Using something like Visual Studio and it's, A very productive way of doing that development.

Q: Is there a tutorial for running FreeRTOS from a emulated environment such as QEMU?          

Yes, you can get started following the instructions on this site: https://www.freertos.org/install-and-start-qemu-emulator/

Q: Is there a regression test suite to validate new ports of FreeRTOS to 3rd party ASIC hardware?           

See https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html#Testing

Q: You have mentioned that you have many bots testing FreeRTOS code continuously. Are these bots emulated platforms or real embedded hardware boards?

Bots are used to build and test on emulated environments - but we also have a lab with many (around 20) boards for nightly testing.

Q: I am using MK66F now with MCUXpresso SDK and FreeRTOS, it works great.  However, the older device MK61 does not have the same enablement environment. How easy is it to migrate the FreeRTOS in MK66F down to MK61F with older KDS IDE?        

Exactly the same FreeRTOS port files will run on both.  You would just have to create a project. See https://www.freertos.org/porting-a-freertos-demo-to-different-hardware.html

Q: What is is the minimum requirement for running FreeRTOS on the NXP controller family? Is MKExxZxxx family able to run with this?    

The requirements are very low. You can find some rough minimum estimates here:  https://freertos.org/FAQMem.html.   Obviously it's going to depend on what exactly you're trying to do, but it is very low overhead. FreeRTOS is available in MCUXpresso SDK for the KE families.

Q: Does FreeRTOS Memory Protection Unit (MPU) supported and available for RT1170?              

Yes.

Q: What is the difference between downloading the SDK from the "MCUXpresso SDK Builder" website and just installing it with the "Install new plugin SDK" button directly in MCUXpresso? 

The direct download in MCUXpresso adds the entire SDK.  The MCUXpresso SDK Builder allows you to include/exclude particular items.

Q: What compilers can be used for free with MCUXpresso?       

MCUXpresso SDK supports MCUXpresso IDE, GCC, IAR, and Keil compilers. MCUXpresso IDE and GCC compilers are available without cost.

Q: Is there a git repo where access the already built example code from this session?   

To access the AWS/FreeRTOS project files, please visit www.nxp.com/FreeRTOS-webinars, click on today's session "Quickly Add Connectivity Using FreeRTOS Components (coreMQTT)”

Q: How does FreeRTOS support the programming and control of a distributed IOT project with many interconnected devices?             

FreeRTOS is device level (embedded) software and only operates locally. It includes libraries that can be used to connect the device to AWS IoT cloud services such as AWS IoT Core, AWS IoT Device Management, and analytics such as AWS IoT SiteWise. For more information go to www.aws.amazon.com/iot

Q: Are FreeRTOS lOT libraries limited to AWS cloud services?   

No. It is open source, implements open standards, and distributed freely under the MIT open source license. However, AWS works with silicon partners such as NXP to qualify devices for AWS IoT services. Please refer to the AWS Partner Device Catalog.

Q: FreeRTOS and OTA-Updates: How can this be done? Is there any support from RTOS/NXP to support that?  

You can perform OTA updates in any way you wish, including using AWS IoT's OTA service.  See https://www.freertos.org/ota/index.html

Q: Can FreeRTOS be used in higher-end processors with microcontroller cores like the i.MX8 family?

Yes, you can find SDK support in v2.11.0 on https://mcuxpresso.nxp.com  Look for support by board and select EVK-MIMX8MP.

Q: What support is available with FreeRTOS for NXP asymmetrical core communication like on the i.MX8 family?               

You can use Stream and Message Buffers for core to core communication in AMP configurations - see https://www.freertos.org/RTOS-stream-buffer-example.html  and https://github.com/FreeRTOS/FreeRTOS/blob/main/FreeRTOS/Demo/Common/Minimal/MessageBufferAMP.c

Q: Can I run Linux on some cores and FreeRTOS on others to get the best of both worlds?          

Yes, this is a common use case.

Certifications

Q: What can I show during a certification assessment for my product, which requires MISRA, in order to show FreeRTOS's compliance, at least at kernel level?

               

Different tools will come up with different rule violations on the website you will find a page that actually has the original. It'll still for PC lint for the kernel, but not for the other libraries. The configuration file that configures lint for them is rules is what I'm trying to say, so that's published so you can see that in the code you will see comments.

So where there's an exception to a rule, the rationale for the exception is actually in the code, as well as like a special magic sequence you put to tell the static checker to know. So you can re-run exactly what  we run and see that for yourself. Different tools highlight different things, so we don't use all the tools.

Q: Is RTOS applicable for the automotive industry? Does it satisfy all automotive standards (ASIL-D,...)

FreeRTOS is used across all industries (including space).  If you require a particular certification, such as ISO 26262 then you can perform the necessary work yourself, or alternative go to a third party to provide that for you.  In particular our strategic partner WITTENSTEIN high integrity systems provides certification packs for FreeRTOS for a number of different safety standards.

 

Q: What about safeRTOS? Is that also supported with NXP. Is safeRTOS needed to be able to safety certify code?

Yes, I say so SafeRTOS is a third party product, so I can't speak authoritatively for it, although I yeah I was involved in its development is that's provided by a partner company, a strategic partner company. I should say Wittenstein high integrity systems. And so that certified or pre certified and comes with all the artifacts you would require in order to do things like automotive. I can answer that question at the same time automotive development as well. It's not directly supported by us, but , we like I say there are strategic partners so we talked to them regularly and yeah I can't talk for NXP support of it, but I know it runs on NXP hardware.

Just to expand on that from an NXP standpoint.  It would be up to the company to get the actual safety certification, but there's really nothing blocking the customer from running on any NXP controller or device.  It is pretty trivial to add support if it's not already supported for that device. So it shouldn't be a blocker.

Q: Has FreeRTOS ever been used, or possibly certified, in a DO-178C aerospace environment? 

I am aware of FreeRTOS being using in aerospace (and space) applications - but was not involved in these projects so don't know the path taken for the safety case.

Q: Has this software been used in as Arm PSA certified application?      

Yes

Application Specific

Q: Where can I find more information on how to use AWS Shadow?      

There is a parameter for the name in this API https://github.com/aws/Device-Shadow-for-AWS-IoT-embedded-sdk/blob/main/source/include/shadow.h#L722

Q: Does FreeRTOS support a GUI library for display applications?            

We don't provide a GUI library ourselves, but multiple GUI vendors provide FreeRTOS integrations.

MQTT

Q: What exactly is MQTT?          

There is excellent material provided on the mqtt.org website: https://mqtt.org/getting-started/

Q: Do make a TLS connection to the broker for each MQTT send/recv and then disconnect or do you connect once and then simple send and recv as needed?

Just connect once. The thing with IOT is at nearly every answer you could say, it depends how you're going to use it. So if you many people will connect once, you definitely don't need to reconnect every time you send and receive, so you can open a connection, leave that connection open and for as long as you like there will be, you know, keep alive messages are generated automatically if you're using the agent and. Yeah, that's a very common use case now. If you're doing a battery powered low power application, like a soil sensor as an example. Maybe you're going to wake up twice a day. You're not going to keep a connection open all that time, so it might be that you create a connection and only send one message and then close it again. But that's purely an application choice. The protocol doesn't say you have to do that at all.

Q: Is it safe to use MQTT library from several concurrent threads, in other words, is it thread safe?

Yes, so there are several ways you can use the core MQTT library.  I've try and talk about it in a way which doesn't make it too complex. If you provide people lots of options, you make it sound complex, right, but Single thread is no problem at all if you're if you are using it in a in a simple application, but from multiple threads you can just use mutexes to protect it

Firstly, if you if you've got a large enough processor to have a lot of multithreading going on and you want to have the MQTT protocol managed for you (so you don't have to worry about retries or sequencing or anything like that), the agent will run it in a thread. So it'll do all that for you and then provide you a very simple interface.

So if you go for the multi threading it you know it's still the same core MQTT library, but it it's running a thread then you can do things like access it from multiple tasks without having to worry about it at all. You just call the API. It serializes it by running it within a thread that if you are familiar with the way our TCP IP stack works, it works on the same principle as that. And if you're doing that, you can do things like have your application task using MQTT and our OTA agents, remember I just mentioned a moment ago that you can stream over the air updates through MQTT. You can have those running in parallel without having to have any consideration for the multithreading at all. So yes, whatever is right for your application, basically.

Q: Is the FreeRTOS MQTT library originally developed from scratch by FreeRTOS community, or it is based on other third party implementation?    

Developed from scratch so we can author along with memory safety and other proofs.

Q: How much of stack memory is necessary for MQTT client on the target NXP MCU?   

Visit FreeRTOS.org and go to the libraries tab. So each of the libraries has a page like this and down there you can see the code sizes. It's about 7 kilobytes. If you have the agent as well, that's going be larger.

Q: What is the basic difference between HTTP and MQTT?         

MQTT is a data centric protocol whereas HTTP is document-centric protocol. HTTP is request-response protocol for client-server computing and not always optimized for mobile devices, while MQTT publish/subscribe model provides reliability of the whole system. MQTT is faster than HTTP. (referencing https://hashstudioz.com/blog/connecting-internet-of-things-iot-with-mqtt/#:~:text=MQTT%20is%20a%20da....)

Tools

Q: What does TAD stand for?    

TAD is an acronym for Thread Aware Debugging.  In the IDE the debugger is capable of identifying the different threads and can providing information on those threads for debugging purposes. 

Q: I always use Matlab/Simulink tools to generate my model-based design into C/C++. How reliable FreeRTOS?               

That is hard to quantify, but needless to say FreeRTOS is 20 years old so has been used in a LOT of applications, with very few bugs reported.  We also do extensive testing, security certifications, as well as have a growing number of formal proofs.  Here is an independent perspective: https://forums.freertos.org/t/what-are-known-freertos-issues-where-is-the-errata/14634/2

Q: What tools are available for debugging multitask applications using FreeRTOS?          

We showed some of these in the third webinar (here).  Several IDE vendors provide FreeRTOS plug-ins, and there is at least one fully thread aware plug-in for FreeRTOS in the Eclipse marketplace.

Q: Does Ozone record assembly level code coverage and does it support modified condition decision coverage (MCDC) coverage analysis? Is the code uninstrumented?            

The Code Profile Window in Ozone displays the code coverage on any level: File, function, source line, and assembly instruction. The code coverage information does not only show which lines have been fully executed (i.e. ALL instructions of a line are executed), but it can also show where conditions have not yet been fully met, i.e. have not been true and false. 

With Ozone and J-Trace PRO, code coverage analysis is completely non-intrusive. It does not require modified code or alter the execution.

For more information, please visit www.segger.com/ozone.

Q: Is it possible to monitor and trigger off of software variables with Systemview? Is this supported with SWD or do you need full JTAG?       

Monitoring and triggering off of software variables is something you would do in a debugger, e.g. Ozone, using a watch window and/or a data breakpoint. SystemView is used to capture tasks, interrupts, timers, resources, API calls, and user events. For more information, please visit www.segger.com/systemview.

Q: Is there a specific benefit of using stack overflow checking against using the MPU?      

A little bit about stack overflow checking, so I did mention the MPU. If you're using the MPU version of process, there are two ports for these Cortex-M architectures. There's the standard ports, and there's the one with the memory protection unit support. If you are using the one with the memory protection unit support automatically, it will put a memory protected region around the stack and that means if the stack pointer goes out of bounds, it will generate a memory fault. But it will generate a memory fault before any data gets corrupted, so it allows you to recover from it gracefully or shut down the machine gracefully and it gives you an option to stay in control over the system, so that's a nice feature if you are using the standard version of FreeRTOS without the memory protection support, then the Stack Overflow detection is done in software.

The two methods it uses, the first method is not that reliable, but it's very fast. The second method uses a fairly kind of standard red zone at the end of the stack. And it will then check On a context switch at the red zone hasn't been trampled over, so hopefully you can catch a Stack Overflow before it occurs in the you know, the red zones got really small. You've overwritten an unknown pattern at the end of the stack. But you can't guarantee that. Firstly, you can't guarantee that you are going to catch all stack overflows, although it's the vast majority will. But secondly, if the stack overflow actually occurs, then you know that some data is being corrupted. And that gives you fewer options to try and recover from that.

I think stack overflows are probably the most common source of problems. It's really worth again at the beginning of your design and periodically through your design, turn that on and just have a look and see how things are progressing. Because the other thing is I was talking about using Segger tools for optimization. The other thing with checking how much stack your task is using that quite often you give a task way more stack than it needs and you're just wasting RAM. I think in RTOS applications RAM is always the most precious resource, so it's another way of optimizing your kind of memory usage as well.

Q: What are the requirements for using SystemView Analyzer? Is it easy to integrate into a working project using Ozone for debugging with a J-Link Pro? Are additional licenses required?           

On the target side, a small software module, containing SYSTEMVIEW and RTT, must be included in the project. The combined ROM size of RTT and the SYSTEMVIEW modules is less than 2 KByte. For typical systems, about 600 bytes of RAM are sufficient for continuous recording. For system-triggered recording the buffer size is determined by the time to be recorded and the amount of events. In terms of hardware, only a SEGGER J-Link or J-Trace probe is required. The CPU requires less than 1 us for typical events (based on a 200 MHz Cortex-M4 CPU), which results in less than 1% overhead in a system with 10,000 events per second. Since the debug interface (JTAG, SWD, FINE, …) is used to transfer the data, no additional pins are required.

Continuous real-time recording with SystemView can be carried out on any system supported by J-Link RTT technology or using a network connection or serial line. RTT requires the ability to read memory via the debug interface during program execution which is generally supported in Arm Cortex-M processors.

It is fairly easy to add SystemView to a target system. As mentioned above, a small number of files need to be added to the makefile or project. In a system without RTOS or non-instrumented RTOS, two lines of code need to be added to every interrupt or function which should be monitored.

SystemView is free for educational and non-commercial use. For commercial use, a license is required.

For more information, please visit www.segger.com/systemview, https://wiki.segger.com/SystemView, or https://wiki.segger.com/FreeRTOS_with_SystemView.

Q: Does the NXP LPC54608x have the ETM-Trace support?         

Yes.  The LPC54608x includes ETM Trace for enhanced debug capabilities.

Q: To take advantage of J-Trace, what maximum ratio is allowed between CPU clock and trace clock? I saw a post on NXP's forum something about a 2:1 relationship between CPU clock and trace clock, but that trace clock can't exceed 100MHZ, which means trace can't be used with RT1170 that runs at 1000MHZ.

The 2:1 relationship between CPU clock and trace clock is also what we at SEGGER recommend. J-Trace PRO can work with trace clocks of up to 150 MHz (300 MHz CPU clock). Otherwise, the CPU speed would have to be lowered in order to do tracing (which might not always be possible).

Also see the recording of a NXP - SEGGER webinar on tracing on the RT1170 here: https://www.nxp.com/design/training/instruction-tracing-and-live-code-coverage-code-profiling-on-nxp...

Q: Do you mind talking about MMD (Monitor Mode Debugging), such as stop at breaking points won't offend bluetooth stack which can't be stopped, etc.     

Monitor mode debugging describes the capability of the CPU to maintain essential functionality while being debugged. This is particularly important when hardware such as a motor has to keep running, or to keep communication links connected.

The default debug mode for most common CPUs is ""halt mode debugging"", where the CPU halts on a debug request, causing the user application and, depending on the CPU, also peripherals to stop execution. However, for certain applications and environments it may be necessary that parts of the user application continue execution while the CPU is in debug mode and the user is debugging another part of the application. This is where monitor mode debugging provides essential improvement.

For more information, please visit https://www.segger.com/products/debug-probes/j-link/technology/monitor-mode-debugging/

Q: Can Ozone Trace/Coverage/Profiling work with SWO interface?

You can activate SWO in Ozone by enabling it through Edit => Trace Settings =>  Trace Source: SWO and leave Clocks on Auto. However, only basic printf SWO debugging is supported by Ozone, because of the limited capabilities of SWO compared to ETM trace. SEGGER's Embedded Studio IDE does support more advanced SWO tracing functions.

For more information, please visit: www.segger.com/embeddedstudio

Q: What can be the expectations concerning system stability when a stack overflow is detected?

Even though it is probably intended for development purposes only, could that feature reasonably be used for implementing fail-safe behavior in production code?

If you use the MPU to detect stack overflow then the memory fault occurs before any memory corruption - and that can be used for fail safe behavior in production code.  Without the MPU you can only detect memory corruption after it occurs so you cannot make any assertions about the system state, and that cannot be used for provable (just probabilistic) fail safe behavior.

Q: The TRACECLK can only run as low as "system clock divided by two", so for big fast Cortex chips (say, at 400 MHz), 200 MHz over a MIPI connector doesn't allow for reliable tracing.  Even the debug pods with adjustable skew drivers can't get a good enough signal.  Do you have any advice (white papers, etc.) on how to practically get high-speed trace out of fast Cortex-M processors?    

The higher the CPU frequency gets, the more difficult tracing becomes.

The 2:1 relationship between CPU clock and trace clock is also what we at SEGGER recommend. J-Trace PRO can work with trace clocks of up to 150 MHz (300 MHz CPU clock). Otherwise, the CPU speed would have to be lowered in order to do tracing (which might not always be possible).

But sometimes even the TRACECLK I/O pad on the MCU can't support the required frequencies.

Please see the following links for more information:

https://blog.segger.com/current-state-of-the-trace-market/

https://wiki.segger.com/General_information_about_tracing

Q: Do Ozone and/or SystemView provide information about interrupts running "above" FreeRTOS (i.e., bare-metal interrupts that don't touch the RTOS)? 

Yes, this is definitely possible. In Ozone, you can set a breakpoint on the ISR, single-step through the ISR, see the ISR on the call stack, etc.

For recording / analyzing the interrupt in SystemView, you need to add two lines of code to the interrupt service routine (on entry and on exit).

For more information, please refer to www.segger.com/systemview, or the SystemView User Guide (https://www.segger.com/downloads/free-utilities/UM08027)

Q: In term of connection, is it better to use SWD or JTAG (for better efficiency)?             

If a chip offers both SWD and JTAG, I recommend using SWD. It is a newer, more efficient protocol specifically designed for debugging. It also uses less MCU pins (2) than JTAG (5 pins). 

Q: What is meant by "non-commercial" use for Segger tools?  Are there commercial options?  

SystemView is free for non-commercial and educational use.

"Non-commercial use" means using the software for teaching, learning, studying, or projects that do not have a commercial background. If the software is used for products or services intended to be sold, the use is considered to be commercial.

"Evaluation" means you are trying out the software for possible future use. While the length of this time period is up to you, once it becomes a standard part of your workflow we no longer consider it evaluation.

For details on the license information, please visit https://www.segger.com/purchase/licensing/license-sfl/

Q: Does the code need to be instrumented for the FreeRTOS aware debugging in Ozone?           

We do have a plugin for Ozone for FreeRTOS awareness. There's no instrumentation necessary for that.  All you need to do is load that plugin.

When you first load a project using FreeRTOS, Ozone analyzes the project. If it detects that the project is using FreeRTOS, it will ask if you want to load the plugin so you have the awareness for FreeRTOS.

For more information, please visit https://www.segger.com/products/development-tools/ozone-j-link-debugger/technology/rtos-awareness/

Q: Please describe the details of the CPU Load window in SystemView?

The CPU Load window is linked to the time span displayed in the Timeline. The time span displayed in the Timeline window is divided into a configurable number of bins displayed in the CPU Load window. For each context its active time is displayed relative to the corresponding bin width. The CPU load distribution in a bin is shown in order of context priority. The number of bins can be adjusted for finer or coarser time granularity. When using a single bin the CPU load ratios are calculated over the entire displayed Timeline section.

Q: Do you have any reference document on how to configure the Eclipse IDE to use the Segger debugger?         

For information on how to configure the Eclipse IDE for use with the SEGGER J-Link debug probe, please see: https://wiki.segger.com/Eclipse

If you want to use the Ozone debugger instead of the Eclipse debugger, simply set up a new project in Ozone for the target device you're using and open the .elf or .axf file generated by Eclipse during the project build. 

Q: All SEGGER tools work with SWD interface, right?

Correct.

Q: Does SystemView need J-TRACE?      

No. You can use SystemView via the regular SWD or JTAG debug connection provided by a J-Link. (But of course you can use SystemView with a J-Trace as well.) 

Q: Does the SystemView and/or Segger tools handle dual core processors?        

J-Link can be used for multi-core debugging. See J-Link User Guide for details. SystemView currently does not yet support multicore devices.

Q: Is Segger Ozone included in the cost of the J-Link debug probe?

Yes, if you have a J-Link PLUS or higher J-Link model. For a comparison of the available J-Link models, please see: https://www.segger.com/products/debug-probes/j-link/models/model-overview/

Q: Which SEGGER debugger models support Instruction Trace / Code Coverage / Code Profiling?            

The answer to this depends on the type of tracing you would like to do. To do any meaningful kind of tracing, the target device should at least provide an on-chip trace buffer (ETB or MTB).

For such devices you can use a J-Link PLUS or higher to do Instruction Tracing / Code Profiling / Code Coverage with Ozone, because the J-Link can read the on-chip trace buffer via the regular SWD or JTAG debug connection when the target is halted.

The best results you get with target devices that include an Embedded Trace Buffer (ETM). Such devices have separate trace clock and trace data pins that allow trace data to be transferred to the trace probe. In this case, you need a J-Trace PRO trace probe to stream the trace information to the host computer while the target is running, either via GB Ethernet or USB 3.0.

For more information please see:

https://blog.segger.com/current-state-of-the-trace-market/

https://www.segger.com/support/training-classes/webinar-advanced-debugging/

https://wiki.segger.com/General_information_about_tracing

Q: How can I replace MCU DAP link with J-Link firmware to make a J-Link base, for example, on a i.MX RT1170 EVK?               

The following AN13206 covers the process for updating the debug firmware to evaluation of SEGGER J-Link probe.  https://www.nxp.com/docs/en/application-note/AN13206.pdf

Q: Do you have any stress testing tool (as part of FreeRTOS or third party), which verifies the behavior in the worst case scenario, when CPU is 100% loaded with real firmware threads and possibly with synthetic thread concurrently?

So I think there isn't a tool as such which is going to do that because it's going to be your application code, which is going to be utilizing the MCU. As far as the kernel is concerned, and I think all of the kernel ports that are on the FreeRTOS website, at least all the ones created in the last 10 years, come with two examples.

One is just a "Hello World" example which is very simple. Creates a couple of tasks in a queue. It's kind of an introductory project that people can understand. The other is what we call a "Comprehensive Demo" and those comprehensive demos are probably misnamed.

For the last 10 years they've been stress tests for the kernel. So it depends on how much memory you have on the device. It depends on how many of the tests we run simultaneously, but there's an awful lot of integration tests. They're all run pseudo simultaneously if there's only one core and they're all self monitoring and they'll test things like interrupt nesting and they'll test the context switch mechanism and they'll test all the features of FreeRTOS all at once. And it'll use a KH tick frequency, which you know we see a lot of people using that anyway, but for probably a bit faster than most applications warrant, and it's all designed actually to really stress the stress the kernel in particular.

If you are having a more production scenario, especially in IoT, we also have device tested tools which will be more functional testing rather than stress testing. Particularly if you're connecting to something like an AWS IoT core, which is the MQTT broker provided by AWS IOT. There are tools that will test compatibility for those things like AWS IOT device advisor. But they are more to do with compatibility, testing and robustness testing rather than stress testing.

Q: Where can I download the Ozone tool?          

The users manual and download can be found at segger.com.  https://www.segger.com/products/development-tools/ozone-j-link-debugger/

Protected IoT devices using FreeRTOS

Q: What are the benefits of using Secure Element over of just using Secure Flash ?

When it is about protecting things like cryptographic keys, private keys, it's not enough to protect them when they are stored on the device, you must also protect them when they are in use.

When these keys are being used, loaded in memory for signing messages or verifying messages.  That's the main difference between a secure element and secure flash.  Secure flash that protects the actual storage when the data is at rest, but you really need a secure element to protect private keys also when they are being used, like for example during the TLS handshake.

Otherwise it's too easy for an attacker to extract these keys when they are in use by just scanning the memory. So that's the reason why you need a secure element and not secure flash.

Q: Is AWS IOT core somewhat similar to LWIP stack for integrating with FreeRTOS?       

AWS IoT Core is a service offered by AWS for device management and connectivity (https://aws.amazon.com/iot-core/). LWIP is a lightweight IP protocol stack that is used in the MCU. This doc can help understand how to use LWIP with FreeRTOS: https://docs.aws.amazon.com/freertos/latest/portingguide/freertos-pg.pdf

Q: Would the OTA update also support an MCU that does not have virtual address mapping features? 

RT106x doesn't support virtual addresses (no MMU)

Q: Can you point me to a tutorial on using MCUBoot with Cortex M33 processors like the LPC55S69?     

Assuming you're asking about mcu-boot vs. the MCU's ROM booting, we include an optional mcu-boot component as part of our SDK delivery.

Q: Are there any advantages to using the mcu-boot component over the rom boot loader?        

With the ROM, it's really focused on just authenticating code. We have APIs as part of the ROM, so you can use the ROM’s authentication method to authenticate your software chain all the way up if you want.  But the ROM is really only providing authentication service.  Getting the image into the device to authenticate it is left to the application side. That's where the MCU boot has a bit more additional functionality that helps out.

Q: The mcu-boot component can obviously provide additional authentication over and above what the rom boot provides. Are there any OTHER advantages to the mcu-boot component?           

Yeah, so the to not just repeat what Melissa said but the MCU gives us the flexibility to update the code and when I was talking through that flow chart there were specific things we were doing, so we used MCU boot to do this kind of dance between the between the bootloader, the second stage bootloader and the application code to get the new image tested and committed and that kind of thing.  It fits into the workflow.

Q: Does MCUXpresso integrate generation of signed images?   

The MCUX IDE doesn't support signed images. However, you could use a post-build action to run a script to sign the image. Note: You can use a signed image in open or closed mode, but having a debugger attached will cause the ROM authentication to fail due to the device being in an insecure state. So you would not typically debug while using a signed image.

Q: Certificates need to be be renewed periodically. How would I handle this on my device? Is there any recommentation for a certificate authority?

Yes, we mentioned the EdgeLock2Go service.  The EdgeLock2Go service offers a service for issuing the certificates and the benefit of EdgeLock 2GO is that we can actually issue new keys and certificates for these devices through the life cycle of the device.

Meaning even when devices are in the field. And we can do that because we have a root of trust preinstalled into the secure element and shared with the EdgeLock 2GO service which allows the service to authenticate the device when the device connects and to securely prepare and encrypt new keys and certificates for these devices.

So what you can do with that, for example, is to connect your device during the commissioning to EdgeLock 2GO to fetch key pairs and certificates for your device.

And you can also renew this operation during the lifetime of your device.

For example, for renewing the keys and certificates, that's always a good practice.

Or to add new key pairs and new certificates during the lifetime of the device.

And for the question on the on the root CA.

Yes, with EdgeLock2Go we can offer a Root CA if customer don't have one. Or we can also link to a existing Root CA of the customer if that's needed. 

Just just one thing I wanted to add is that's super important, so obviously you use EdgeLock2Go to rotate your certificates.

But those certificates need to be updated in the cloud as well so that you can maintain that mutual authentication.  One thing that EdgeLock2Go does is it has native integration with our AWS IoT device management APIs which allow you to basically associate a thing or the device with its certificate.  So just by exercising the API, which is done automatically through the EdgeLock2Go service.  You have rotated that certificate also in the cloud and your device can maintain its mutual trust there.

Q: How we uploading image on cloud? what kind of server we use for that?      

Sure, so I guess assuming that PKCS-11 output process or the output of a developer building an image is a probably a dot bin file.

And once you have that dot bin file locally on your laptop so you can trigger an OTA update when you go through the configuration, you have the option to upload that image into a service we call Amazon S3, which is essentially block based storage.

So essentially you can just store anything in there so customer using it to store everything from.

Update files for microcontrollers to video files, for example, and then that image stays in there and then the next thing that happens in the configuration process of your OTA update is then you go and sign it and then it.

Once you do the signing, then it makes a copy of that, but it also includes the signed header as well into Amazon S3 and so basically it's all stored into this,, kind of low cost storage, scalable storage option, we call Amazon S3, and those images can live there.

There it's also helpful to keep them there for versioning purposes.

So you will always have all of your old versions of software that have been deployed to your devices and Amazon S3 so that if you ever need to rollback or inspect previous versions, it's all there on Amazon necessary for you.

So you can do OTA's any way you like.  Once you've uploaded your image into S3.

Then as far as the signing services concerned you pointed to PKCS-11 S3 file or bucket as it's called, and then it's part of that device management workflow then is to sign it for you as well, which is a nice feature.

Q: I'm using the RTX1062 and have had to greatly reduce the cipher suites available in mbedTLS to complete the TLS handshake in the time allotted by various cloud services. Can the secure element help with that?           

Yes, definitely.  That's one of the main purpose of the secure element.

And actually that's what we have integrated on this reference platform.

Here we have the RT-1060 plus the secure element, and we demonstrate how using the secure element you can protect the private key for performing the TLS client authentication, and how you use a secure element during the TLS handshake.

And so all of that is now integrated on this reference platform, so definitely yes, yes the SE050 will help for this.

Q: Can a MCU with a "secure flash" to do Root-Of-Trust secure boot replace "MCU with RT1060"? As normally secure flash provide drop-in replacement with XIP support.       

Our newer MCUs with flash include a similar secure/authenticated boot as our flashless parts like the RT family. For the legacy flash devices with flash, but no secure boot, then the flash is treated as trusted. So the idea is similar, but the security is increased in newer devices.

Q: Is PKCS#11 a separate software library or it is included in WolfSSL or other TLS library?          

PKCS-11 is actually an API. It's included in the reference integration as a header file, so you literally just include the header file that's freely available from Oasis.

Oasis maintains that as the standards body.

And with things like mbedTLS, probably wolfSSL as well, they have some kind of native support.

For PKCS-11 as well as you are porting those TLS libraries to whatever hardware that you have available on your production device.

It's worth pointing out that PKCS-11 is a big API and it's used on things like laptops to to access the route of trust on laptops and that kind of thing.

Obviously it's connecting to very sophisticated hardware.

Don't be too intimidated by the size of it because we use just a handful of different APIs from there.

I should also say that for people using PKCS-11 PSA (Platform Security Architecture) API.

We have code that maps that to the PKCS-11 so that makes it even more interoperable.

Q: What are possible recovery approaches are possible with FreeRTOS if OTA firmware update failed and device remained in inconsistent state?

PKCS-11 OTA has a state machine which is kind of alluded to in the question and we actually have some of the math Wizards that AWS did some formal proofs on in our state machine.  Which is quite good and the basically we don't delete the old image until the new image is known to be good.

So you will have two images on your device at once, and I mentioned that we're doing that self test.

If that self test fails then we will mark that image as bad and the next time the bootloader boots the system it will see that that image is bad and delete it and then eventually on the cloud side it will recognize that.

That particular device was never updated successfully, so it's going to retry or whatever you wanted to do.   You know that you can have a new image on the device, but it's not committed.  And only when you actually commit it, which is a deliberate action on part of PKCS-11 application to say yes, all the tests passed.  Only at that point do we delete the old one.  So you've always got that option.  Anything goes wrong, then you go back to the old one.  I think there's also a watchdog timer.  That is on there.  So if you boot the new image and it just does nothing, then eventually you will, reset and the bootloader will recognize that things went wrong and get rid of the bad image and start executing PKCS-11 old or the pre existing one.

So I just wanted to add one thing about the cloud side.  So Richard mentioned the device reports its status to the cloud.  It's either a succeeded update or it's failed.

When you're configuring your OTA update job, it's not like you just send out to your whole entire device fleet at one time.  So if you send out a bad image and they all fail, you're going to be in trouble.  So the way that you can implement it is just through a configuration option.

You can say if let's say 5% of the devices fail for whatever reason,  you can stop that update in the middle.  So you can also do rolled out, phase rollout type of updates where first you update 10 and then you do 100 and then you do 1000.  So then your blast radius is small so if you do have a failed update for any reason, you can detect that in the cloud.  Stop it before it becomes a bigger blast radius.

Q: What cipher strength are typical and ok for embedded devices running FreeRTOS, assuming constrained hardware, can it be 128 or 256 encryption or more?

On the current RT10xx products, we have hardware acceleration for AES-128. You can use AES-256 or other symmetric ciphers with a software cryptolib (we have options in the SDK). You'll get the best performance using the hardware accelerator, so we recommend using AES-128 as much as possible.

Q: Bootloader is a part of FreeRTOS or it is provided by the vendor of hardware?            

NXP does provide mcu-boot as an optional component in our SDK.

Q: Are there any portions of AWS for firmware update that needs to be implemented by the product developer or is it just a matter of configuration?            

So I think part of it is that when we talk about the developer.  The developer is typically working for some sort of device maker, maybe an original equipment manufacturer or smart home device maker.  Obviously you have different roles at that company, but a couple different personas that are required to be in the process from the entire device lifecycle.

Obviously you have the developer who's building the embedded software that goes on these devices, so the FreeRTOS.

Application and then that developer is probably responsible for, patching, building new updates, new features and then going to the OTA process.

You've also got like a device fleet operator who's responsibility is device management to understand what's happening with your devices, what's happening with your certificates, your mutual trust, your PKI responsible for rolling out the device, management updates so they get PKCS-11 update image from the developers.

Now they need to roll it out to their device management team and then of course you've got operations and procurement.

Who is responsible for sourcing all the components.  So you have to source the processor.  You have to source all the components that go on it.

So the device is not done once you ship it to the contract manufacturer and say make me a million of these, you want to kind of maintain control of your devices throughout their entire lifecycle so that you can always give your customers the best experience.

Make sure that they have the newest updates, newest critical security updates, and also there's the application that probably runs in the cloud.

Which is like maybe a mobile application for smart lighting device.

So all of that is part of this whole process.

So if you remember my slide, I was kind of talking about the complexities of managing all of that at once, and so that's kind of what we're attempting to make a little bit easier for customers to do.

I called out at least five people.  So rest assured, for the developer, the fleet manager or the operations person or PKCS-11 different, there are more people just communications key.

Make sure you own your piece and communicate with PKCS-11 other individuals.  What will become apparent in the next two webinars is that when in the development phase then the developer has to know what's going on with the keys.

And added putting keys on the device so it's very, very different to the production phase. Where the developers kind of out of the loop.

Q: How can the boot loader get the application to run self tests after booting the application? 

It tells the application before it boots the application.  There are some status bits in nonvolatile memory that allow PKCS-11 boot loader the boot loader to communicate the status to the application.

So PKCS-11 application will see that it's a new image and it needs to go into a test mode 1st and once it's committed, by committing. Is actually saying OK.  This is the image we want and it has to have a higher version number.

And then when the bootloader.  It's actually PKCS-11 agent that sets the PKCS-11se bits which are used for the two to communicate to say that that is committed at that point.

So the next time it boots, it will just boot into the application normally rather than asking the application to do a test.

Q: How do you generate the signed images that work with the RT 1060 ROM?  

OK yeah, so for the ROM we have a variety of tools available.

Probably the easiest tool to use is that we have an MCU secure provisioning tool, so we call it our SEC tool and it gives you a GUI that'll help you walk you through the process of.

Signing your code, blowing fuses, and doing all of PKCS-11 secure boot setup that you need to do for the park.

And we do use that part that tool across our MCU product line so it works on the RT products as well as some of our LPC's.

And other devices, so that's probably the first stop, especially if you're just kind of getting familiar with it and don't know quite where to even begin.

We also have an SP-SDK tool, which is basically the command line version and PKCS-11 set tool GUI is actually built on top of the SP-SDK, so for power users, or once you're actually ready to move to production and you want something that's like scripted, you may want to move to that.

SP-SDK versus using SEC.

Q: How much time the verification of the boot image signature can take on the edge device, how this affects boot speed on constrained devices?

Right, and as with most things, the answer is it depends. There are a number of variables that go into what impact the verification is going to have on your boot times it will have an impact, though I guess that's really the most important point is that it's not free. And there, and we have two different verifications potentially going on with this setup, so. At least as delivered, the reference design is using the MCU boots verification to verify the app, but once you get to a production environment you would want to use the RT 1060s boot rom, which has a feature called High Assurance Boot, so you would want to use have to verify the second stage bootloader and then the second stage bootloader would verify your application.

So you've got two different verification steps, and if you have additional software layers, you could have even more. They're doing similar things so the boot times are not the effect of the verification. It is probably going to be somewhat similar between the ROM and MCU boot, but it is completely different code base. Those times are not going to be equivalent. Because MCU boots very small, you should see your pretty minimal impact

From the BROM side getting to MCU boot, but then the actual application is really that's where your most of your code is going to be. So really depending on your application size, the boot frequency, and how fast are you running the core?

How fast are you running your FlexSPI interface? To the external flash, those are really going to be the big factors that determine how long that boot time takes.

Q: Is there any MQTT broker compatible service with AWS IoT offer?    

So if you have an MQTT client, as long as it can speak to the Endpoint and make that mutual

authentication with AWS IoT core, then you can use any MQTT client to connect into AWS IoT core.

Then once you're in AWS IoT core, once the messages are in what can you do in the data? That's actually there and gone over the broker.  AWS IoT has a rules engine called AWS IoT rules engine, where essentially you can preprocess the data, so maybe you can filter messages based on the topic space, or maybe you're only looking for a message if one of the values is over 50, for example.

Then you can route that to a number of different types of databases within AWS and other types of AWS services or even external APIs. So then you can say I want this message to go and contact this API and post it to that API. So once it's in the AWS IoT core message broker over MQTT, from that point you can route it to any AWS service or external service that you'd like.

You can do all sorts of analytics on there or data to store it in a data lake, mill or whatever. Whatever you're going to do with the data is actually how you get the value from it.

But also MQTT is just a standard, so you can connect to any broker which is known to comply with those standards. The OTA service that we showed is specific to AWS IoT. It's kind of completely integrated into the device management. You can see how this kind of integrated with the signing service, for example.

It's integrated with the Certificate management service. It's integrated with all the device management stuff, so it's a very convenient way of doing it, but as. You can perform out here anyway, like anywhere you like, as you say, but we add that extra value there.

Q: What is the purpose of imgtool.py, what library does it use underneath, is it openssl or else?

imgtool.py is the code signing utility for use with mcu-boot. imgtool does use openssl. Note: the RT1060's ROM authentication uses a different code signing tool (MCUX secure provisioning tool or SPSDK).

Q: Does the secure element protects against physical attack? I.e. if attacker has access to the I2C bus? 

The purpose of the SECURE element is exactly about physical protection and anybody who tries to

access it physically that he cannot get out the keys. 

It means that the prime saying which they can do and does do so, even though if you can access the bus then maybe you can talk to the core element. Yeah, but what you never can do is you never can get the key out. So as long as you don't enable additional measures here, you and anybody can talk to it. So by default the communication is not encrypted.

So to make it easy, yeah you can just create objects. You can use the objects inside and then an attacker could simply use the objects. Here he can read certificate, he could use keys inside and sign something,

but you cannot get the key out.

Now it depends on the use case. Yeah, if that is here an issue to you. If somebody can use the key which is inside. And if you want to protect against it, then we have the features that you can turn on.

It can mandate actually see an encryption of the SoC bus so that the secure element only accepts encrypted communication. And typically how you set this up is that each device and something which you do in your production. Yeah, maybe on 1st boot up PC device creates just a random number and that's this random number as OK. This is now my communication secret with the secure element and that's it to mandate it encrypted mode. And then you always need to start an encrypted session using a secret. Actually this has AES128 so it's an AES secret.

Only commands which are encrypted and mapped using the secret then will be accepted by the secure element. But yeah, if you need that, yes, it always depends on the exact use case.

We recommend that it's being used because this exactly then prevents anybody from tampering with the I2C bus. Then only the host which is valid and exactly this one host which has the secret can access and use secure element.

Q: Can the SE050 device certificate and keys be automatically produced during mass provisioning?       

The provisioning of SE050 (insertion/creation of credentials) can be done in many ways, NXP can deliver the secure element already pre-provisioned or it can be done in the field. The provisioning will be also topic of the next webinar in the series.

Q: The demo had a terminal showing the swap-type = test or the swap-type = none.  What was that indicating?               

Yeah, so during the OTA agent expects to interact with the bootloader to know if it received a new image? So what we were showing there was a little bit artificial because we're starting with nothing on the board. But let's think of a normal situation. You are in production, you have an image on the board already, and now you downloaded a new image.

So in the primary slot has what you are executing, and you download the new image into the secondary slot. And when the bootloader starts up, it is going to look at the primary slot First. We saw that happening at the very beginning of the little demonstration. It showed something valid was there.

It is then going to look at the secondary slot, and if it sees something valid there, it will ask ""Which is the highest version number?"" If the version number is higher in the secondary slot then it is going to start this swap. It is going to swap the two over.  It wants to run what you downloaded. That is then going to be in the primary start. It is going to run that, That is when we are going into this kind of test where there is some metadata there and the OTA agent is going to ask, ""OK, this is in test mode, so we want to perform whatever test can satisfy to us that this code is working.""

I always recommend that you at least check that you can still connect to your OTA server so that you can receive another image if there is anything wrong. Then once it has performed that test you can commit to this new image.  Then every time you boot from now it will use that image and it will then delete the second image. Normally we recommend to delete the other image because if you are doing an OTA to patch a vulnerability, you don't want some kind of rollback to the known vulnerable unpatched version.

Q: Is secure boot utilizing the SE050 or HAB?     

i.MX RT1060's secure boot/HAB does not rely on the SE050

Q: Can the bootloader use the SE050 if wanted? Is it configurable to reduce it's memory footprint?       

The ROM would need to be able to support both as we wouldn't want to require that all customers buy an SE050 along with an RT1060. So there wouldn't be any memory footprint advantage. mcu-boot is open source, so you can change it if you want. This would have a large impact to the boot time because of the I2C communication.

Q: How do you recommend protecting the 2nd stage bootloader from attacks?  For example, if I can change that bootloader, I can load unsecure code.  

For production you would use the ROM's authentication (HAB) to verify the 2nd stage bootloader before jumping to it. That isn't being done right now for the reference design in order to make it easier to reuse the board for other things (using HAB requires blowing fuses in the MCU).

Q: Do you plan to add HTTPS example of downloading file from AWS into NXP IoT ?      

While this example isn't ported directly to the example Richard is showing, we do have a library called coreHTTP along with examples of how to download a file from Amazon S3: https://freertos.org/http/s3-download-demo.html This can be easily ported to the i.MXRT1060.

Q: What sort of the steps for getting started with that AWS dashboard and you had mentioned a free tier. What are the steps for connecting adding devices?            

"The reference design that Richard Barry showed from the device side. Obviously on top of buying the silicon and the C050, the code itself is open source and free. You are welcome to clone that off GitHub

When you go to connected into AWS IoT core, you do need an AWS account. You can sign up on Amazon aws.com. and when you do that you're activated for the first year of your AWS into something we call free tier. As long as you stay within certain services that are called out, everything is essentially free.

So an AWS IoT core specifically has a free tier that is available for one year after your data signup.

And what it means is you can have up to 50 devices connected 24 hours a day and you can send up to 500,000 messages within the first year. So 500,000 messages to AWS IOT core or exchanged over our message broker. Everything shown here today is actually within the free tier. You can actually run this example and do your evaluation within the AWS free tier and then once you start to scale up your device deployment then then you're charged the pay as you go model, which is the normal model of data use.

Q: What other examples does NXP or AWS and FreeRTOS have that they could connect with the AWS services if they don't have the secure element?    

So in general, the examples meant for cloud connectivity, of course is something which we share by default are configured without secure element integration. And then we just have a second set of examples which have this enablement of the secure element. So since secure element is here, just always use the next step of security which we offer here.

What we are demonstrating here is a setup which is much closer to what your production hardware will be. If you are just experimenting with AWS connectivity then you can store your keys in a less secure way. We like to demonstrate best practices. There are a lot of examples, but the one that we are going over is more a true reference design that people can use in a real case scenario. If they're just getting started and evaluating, then the NXP and AWS SDK have several examples that can get you from a simple example all the way to a full secure connection like this reference design.

Q: What can be a good security strategy when some edge deices should be decommissioned, but the majority of the edge devices should still operate? Is it automated task, or some operations should be done "by hands"?            

I think there are a couple of different ways you can look at this. The easiest ways to do that is you can simply deactivate, remove certificates from your account and that will prevent a device from connecting on the device. You might want to kind of the equivalent of a factory reset or a self destruct button that might wipe the device, or any potential key material on it as well, something that you could trigger from the cloud side. But maybe you also tie it into a reset button, so again there really are a couple of things that you will want to make sure you take care of and in decommissioning, One is shutting off access to your cloud resources and then the other maybe on the device. Decided to have it perform a factory reset as part of a decommissioning process.

Q: Can the configuration of the whole AWS IoT fleet be backed up somehow (or scripted), so in the case of a global crash, the fleet configuration (including all security certificates) can be restored on different nodes and continue to operate from different datacenter?       

When you say configuration. That could be maybe application dependent, but if we think about this just in terms of device identity/configuration, you could absolutely register these devices into multiple regions.  You know multiple IOT endpoints and use them as failover in a disaster recovery scenario and this is exactly how devices using secure elements are typically registered within AWS IoT core.  It is what we call multi-account registration where you effectively register these devices into multiple accounts. Multiple regions in order to ensure that they have a couple of different places they could connect if they need to.

I'd say the onboarding strategy as to how the devices are registered within the system

when it comes to the application. Config you might be able to keep depending on how large it is,

you might be able to keep that in the device shadow for example, or have the devices reflect their

config as part of an onboarding process and put it in a global Dynamo DB table again, which provides very high availability.

Q: Can it be possible to have edge device firmware, which registers itself in AWS IoT fleet system automatically, once it turned on for the very first time and appear in the list without any manual operation?  

Yeah, so at the beginning we had a link to an application note and I believe that application note describes several different methods of doing that and also just mentioned the multi account registration. So with the secure element you can have schemes where a device will connect. And then get told after it connects to a known account and afterwards is told where to connect to.

There are schemes such as just in time registration and just in time provisioning. Where if a device can get registered automatically, and I did a little webinar about this, perhaps embedded world last year or the year before I forget.

And there's various different schemes and there's also the bulk provisioning where you're getting scripting you can send. There's send everything necessary up to a WSDOT to register various different times during manufacturing as well.

We have features like just in time provisioning or just in time registration that really leverages the device PKI. So the if you're able to register the CA, the certificate authority that signed that device certificate in your AWSIT. And then the service if a device connects and presents a certificate and a device that the service has never seen, it will then look and see.  "Hey is it some something that I recognize as trusted?" Because of this, the CA registered in the account and it will automatically register that device. So you could envision having a couple of different accounts or a couple of different regions set up with the CA registered so that your device may look at. You know one IoT endpoint or the other? You know the unique string Uri the device uses to connect and use that to on board the device. That way there's a really good white paper on device provisioning and on boarding that that I can refer you to as well.

Yeah, so that just in time provisioning from the developers perspective, you have to be aware that when you first connect it doesn't know a device. This connects. It will then get disconnected because the first time you connect the client service doesn't know who you are, but as Ben just described,

it can then check to see whether the CA is known that was signed. So you'll connect and then it will disconnect you and then you that kind of triggers a back end process. Then you wait a very short period and then connect again and then the second time it will allow you to connect.

There are also more managed processes. Well, I mean, there's the EdgeLock2go that we talked about. I think it was in the 1st of this series of three. So the 4th webinar overall and there's also.

A new method that we have called Express link which went in preview at our reinvent, which is the AWS' biggest conference of the year. Where the identity and all the connectivity software is actually on a radio chips. If you are putting like a Wi-Fi radio or a cellular modem or something on your device.

All of the software and the identity and the certificates are all pre provisioned on there and there's a very managed workflow to have that automatically registered in your account as well. So there's lots of different options.

Q: Can AWS IoT provide root certificate authority to sign Edge devices certificates, or root certificate authority infrastructure is always on the customer (developer) side?        

We do provide APIs to allow devices to export a Certificate signing request to CSR that can be used to for the Amazon Route CA to sign and provide the device certificate or provide the certificate back to the device. You know when it when it comes to keys and where they're stored.

The private keys always have to stay close and protected to the source of that data. So on the case of the device identity that that private key is generated and that edge lock SC050 and never exported. Not even directly accessible. To the application, it's only used as part of the TLS session. The devices that service holds the OR recognizes the certificates which hold the public side the public key when it comes to PKI, we really support both. You can either use AWS PKI to underpin this. This is actually what the development flow is for when you create a device. It creates a certificate for device that is signed by the WSCA and then RPKI or you can bring your own PKI and you can have

the whole public key infrastructure external to the cloud and maintain all the keys yourself and then just add  the registered CA that you were trusting for these devices into IOT core. You can go both ways depending on your security model.

What do you do if you got a brand new board and you want to develop and connect? If you look at the slides for that, which I believe you can download from the NXP website, there was actually a command where we were actually using the AWS CLI to send that up to the Amazon certificate management. Service so that again is a not a demonstration of how to do it securely in a sense that it was just a development time thing.

Q: I'm curious about the device/thing security features of the NXP LPC55S69 Cortex-M33 based microcontroller, how they compare against the combination of the RT1060 and SE050. The 55S69 seems like a lower cost, lower power processing element with secure on-chip memory. What is it missing in terms of security features and NXP tools to connect to AWS IoT Core.          

The RT10xx parts and LPC55Sxx devices are pretty different classes of device. The most obvious differences being the RT10xx is much higher performance with an M7 compared to the M33 on the LPC. The other being the RT10xx runs from external flash instead of internal flash. Both families of devices do have security features implemented. There is overlap in a lot of the features although the implementation of the features have differences. All that said, you can absolutely use LPC55Sxx parts with AWS. The SDK includes optional AWS examples for the LPC parts.