Embedded - 218: Neutron Star of Dev Boards

Episode Date: October 6, 2017

Dirk Akeman of SEGGER (@SEGGERMicro) joined us to talk about debugger specifics. Ozone standalone debugger for use with J-Links SystemView visualization tool for RTOS and system debugging Jlink Products Turning an ST-Link on a development board into a J-Link We recently did two other shows on debugging: a general intro with Alvaro Prieto and one with a focus on the development-system’s debugger software interface with Pierre-Marie de Rodat. Herd immunity and find a flu shot And, yes, we did bleep Dirk's answer for favorite processor because he later reconsidered the idea that he only had one favorite.

Welcome to Embedded. I'm Elysia White, here with Christopher White. Our guest this week is Dirk Ackerman of SEGGER. Hi, Dirk. Welcome to the show. Hello, everyone. Glad to be here. Could you tell us about yourself as though we had met at a lunch table at a technical conference? I've been technically from the beginning, basically, starting as Commodore 64 in the 80s and started programming as a U.S. guy and continued that during my studies. Though I still tried to get more into an engineering background, so into electrical engineering

and ended up with some mixture of economics and engineering during studies. So I had some industrial engineering degree in the end, continued as a research fellow. And there was a very interesting part which I did was basically a hardware loop thing which was based on the PowerPC back then that made me dive into the hardware, dive deeper into the software and stuff like that and controlling things actually and making things move. So that was basically my first embedded experience I had. And when I left university, I went away from software actually because at some point there was always a feeling it's not finished yet.

And I wanted to do something different, try to find out, get that feeling away. So I went to a distribution company who looked for an application engineer, stayed there for a while. And then I met Rolf Sager and got the offer to work for him as partnership marketing manager and I had basically everything around what I had in experience. I could put in my economics background, my technical background, was back in software because Zegger is a software company. So now I'm here. That was 2009 actually when I joined Zegger.

So it's a while back. And I'm quite happy to be here. We've been growing since then. I'm actually growing for 25 years now. But the last years have been really incredible and the department I work in no longer is just me, it's a couple of people. So my workload has shifted to other people and I've gotten new tasks and stuff like that. So that's basically my career in a nutshell. All right. in a nutshell. Alright. Well, we're going to ask you more about some things at

SEGGER, in particular the JLinks and JTraces and JWhatevers. Yeah, what's to be expected. Everybody knows us for them. But also some of the other SEGGER things. Before that, we'd like to do

lightning round, and I know you listen to the show, so you're familiar with the goal of short questions with short answers. And we'll see if that works out for you or us. Chris, do you want to start? Sure. Favorite book or movie which you encountered for the first time in the last year? All kids' movies are kids' books. I have a four-year-old.

That's a fine answer. Not really a favorite. I don't know. Having a four-year-old, do you have a least favorite? Something you've had to see 97,000 times? Or read? The funny thing is, if she enjoys it, I enjoy it too. Do you have a favorite technical conference to attend?

Definitely the Embedded World at Nuremberg. That's a big one. It sure sounds interesting. That is an interesting show, and everybody should go there, really. I think I wrote you an email in the past where I said, go there. And I really mean it. It's just incredible. You meet everybody.

And it's big, but it's still, compared to other shows, it's still small because the embedded industry is not a huge industry. It's the most exciting industry in my point of view, but that show really shows it. All right. SWD or JTAG? I don't care. Favorite processor? I shouldn't say that but which one was it okay

least favorite processor I'll shut my mouth to that one that's very politic favorite language English but I guess in my programming language, so let's see. We're ambiguous. It was pretty ambiguous.

You mentioned Commodore 64. What's your favorite computer, or do you have the best memories of that one or something else? Actually, my most favorite computer was one that I never had, but did a lot of stuff on. That was the Amiga. Ah, yes. I had the C64, and I liked it for the simplicity of assembly programming.

And there was this, I want to have this thing, Amiga. It was a pretty, pretty impressive computer back then. Yeah, definitely. Okay, one more question. And on that same vein, in the 80s when you were getting into this, which did you most want more of, RAM, disk space, or processing power?

Most times was processing power, actually. Now we have that. We have all of them. We definitely have that, yeah. You said that the, so moving away from lightning round, you said that the embedded industry was exciting. I, of course, feel that way myself.

But why do you say that? What makes it exciting to you? As I said, when I have been a research fellow at university, this project which I had where I had to combine everything I knew about software, about hardware, and really find out what things make other things move, that was just incredibly satisfying in a way because you could really do something not virtual with software. That's what I really like. And Embedded basically makes things which appear to be huge. If I think about something which we carry around today, that would be basically a couple of years ago from the size of the hardware.

So if we talk about smartphones, for example, you would not be able to carry it in the 80s if you have the same processing power. And the distribution of tasks, small little computing units and get them working here and working there and let them do things together. There's so many things around where you can think about embedded. It's just incredible. Yeah.

The interdisciplinary makes it fun, and the applications, there are so many of them. And like you said, making things virtual into doing something physical. Yeah. That was a big attraction for me, too. And the pace, how fast it changes, you'd think we wouldn't want that because it makes our lives more difficult,

but it's part of the fun part. So, all right, let's talk a little bit about debugging. And I know we've done some shows recently about debugging. We had Pierre-Marie Derodat and Alvaro Prieto talk

about both the software debugging and the whole process. But still, for the people who didn't catch those shows, could you give us a short what is a J-Link, I guess, is the short question.

What is a SEGGER J-Link? Well, the J-Link, I guess, is the short question. What is a SEGGER J-Link? Well, the J-Link is basically the link between the developing system and the target which you want to develop on. As we cannot debug on the system and develop on the system itself, as we could on a PC, we need some link between the PC and that device. And that physical link is a J-Link. And as a J-Link is just not software and just not only hardware, it's a huge software bundle in the end. It's also the software debugger in that. We work with, basically the Jlin can work with its own debugger, the Ozone,

but it is supported by basically every debugger you have in the industry. And if it's just via the GDB server. Yes. So it is hardware and software, and then software on your computer as well. Yeah. software on your computer as well yeah and when i plug it into my uh stm32 f7 cortex processor what what is it talking to in the box what is it talking to in the jlink is there a fpga or is there another processor in there ghosts ghosts it. Ghosts. It's October. Depends on the model. So usually it's a microcontroller of some sort.

If it's a microcontroller inside an FPGA or if it's a microcontroller which communicates via an FPGA or a microcontroller which communicates directly with GPIO, we have different sorts of solutions there. So basically the JAG is an intelligent system

with a microcontroller. And the target interface depends on how we implemented it. For example, if you look into the current JTrace Pro, that has a Zinc in there. A Zinc? What is a Zinc? The Xilinx Cortex A9 FPGA.

And if you look at the Trading Ultra Plus Trading Pro, we have, I think it was a

CM32F4 and FPGA. And on the Trading Base Trading Plus, we have an LPC

43 inside right now. The J-Links do mostly the same thing, don't they? Or are they, do they,

is it that they act faster or slower or what's the difference? Basically, yeah, basically they're doing the same thing

but the plus has some additional software packages enabled so for example if you want to use breakpoints and flash memory beyond the hardware breakpoints if you want to have a programming tool with projects something then you would go for Jading plus and if you want to have a faster unit you can go for Jading Plus. And if you want to have a faster unit, you can go with the Jading Ultra Plus. And if you want to have an Ethernet connection, then you go with the Jading Pro.

And if you want to have trace, so ETM trace in addition, then you go with the JChase Pro. Okay, so what does the FPGA do for you? I mean, we write microcontroller software. That I can kind of understand. There's a protocol and I have to talk to something. But why do they all have FPGAs in them?

On the faster ones, we just use it to quickly modify the signals for the JTAG interface. That's basically improving the response times on the signal side. That's a little bit more to it, but basically we just try to get the most clean signal there. You take USB, I mean, I know there's an Ethernet one, but for the USB ones,

you take USB on one side and then JTAG or SWD on the other side. Is it just a translator between USB and the debug protocol? It wouldn't be so

popular if it was. There's a lot of intelligence inside the JLink which handles the debug unit on the other end. So we can use a much simpler protocol on the USB side. For example, there's an implementation for OpenOCD which talks to the J-Link. If you use OpenOCD, you basically have the dumbest debug probe out there. Then J-Link is nothing else

than a dumb debug probe. So it's just a command translator. And then you lose all the advantages you have with the J-Link because the J-Link inside has a lot of things where you can communicate more directly with the target interface. And with this opportunity, you can be a lot faster, more responsive. You have a lot more options, like direct memory access and stuff like that. So for people who are on the GNU side, it takes a GDB server in that case

because you can also use a GDB and you can use a full. You can utilize your trailing fully. Because the GDB server part is written by Seger and so you can translate better. Yeah, and it's freely available. So if you have any trailing, you can use a GDB server. What do we need to know about choosing our debugger software? I mean, okay. OpenOCD was never on my personal list of favorites.

GDB is okay. I guess Eclipse is usually GDB underneath and Kyle and I are different. Do you have to write individual software for those? And what do you suggest I use? Actually, I would suggest to use two debuggers. One of them is the Ozone debugger, which talks directly to the chaining and always will have the latest features in there.

But that one works with the L file. So you will load the ELF file into the Ozone and then you can work with it as if you would use it inside your regular IDE. If you use it with Embedded Studio, then you can call directly from Embedded Studio instead of using the internal debugger from Embedded Studio. But you can do the same as the IRC spy or KAS debugger. From our point of view, the debuggers from Embedded Studio and the Ozone debugger are better in a couple of ways. A little bit easier to use, a little bit more powerful than some things, but basically all of them work. And we have a long history of supporting all of these.

Yeah, we've talked before about how it becomes a combinatorial problem where you have to support all of the hardware pieces and all of the IDEs and it just... And all of the revisions thereof. And all, I mean, Seger has a whole line of products. So I have to say, how do you even go about

testing all of these combinations? The interesting part about testing is you can do everything. It will take ages. Or you can be smart about testing by trying to find combinations um or if you have a group of processors you usually don't need to test every single one of them so i don't need to test the sdmF746GGAB and the AE. Doesn't make sense.

So you can basically shorten that test, for example. On the IDE side, you basically have to test them all. Again, you can basically, on the GDB side, it's the GDB you have to test. You don't have to test all the GDB based ones. And so you can strip down a little bit on the testing and streamline it and reduce the amount of testing. Now, there are other things where you can do similar things. So it's an enormous amount of testing we do. And we have,

sometimes we have to take shortcuts. So on the better versions we really should take the shortcuts.

On the reduced versions we do not afford the shortcuts because that would basically kill us.

Yeah, if you can't trust your debugger, you really can't trust anything. Well, I was going to ask how you test your own development of JLinks. Do you plug a JLink into a JLink?

I know I've asked this question of other debugger people because I find it hilarious, but do you test your own devices with your devices? Of course. Or do you have special devices? Okay. We also have special tests? Okay. We also, we have special tests in addition. Sure. But we definitely,

yeah, I think in California it's called dog feeding, right? Yes. You use our own products and so when you look into the Jading, then you have our RTOS in there,

you have our USB stack in there, you have our USB stack in there, our IP stack as it's in the IP interface, a file system if you have memory in there. If you have a display like on the Fedlash or Portable Plus, we use our own MN and so on. So we do use our own stuff and that's actually part of our success in many things because that definitely improves the reliability and the usability of the thing. If you have to use your tools the whole day and you are not allowed to use other tools, you make sure that they are good.

Do you have a giant room full of test platforms that you work with? The hardware? We have not automated it. But we have approximately 2,000 evil boards in our office. Oh my god. And it's growing, so we are approaching 3,000 fast. At some point, SEGGER, the building, is going to collapse in on itself

and become a neutron star of dev boards. They're definitely moving next year. How large is your QA team? I mean, they must spend a lot of time testing. We have the training team, which is approximately 10 people. And we have basically every engineer in the company. We have the training team, which is approximately 10 people. And we have basically every engineer in the company. So we have 40 engineers working for Sager.

And 30 of them are in development and they are forced to use our tools all the time. So that's basically one part of the QA team. And the other part is the 10 people in the training department all of them do QA so when we do a release basically they are 100% QA. How often do you end up releasing things? Very often I don't currently I don't recall our cycle. It's like every two weeks or so. That's amazing. That's really amazing. We're not releasing as fast on the other products, but still we have a good rate of releases there too.

Basically, on every product, we try to have one at least once a quarter or once a month, depending on the product. How are the debuggers and programmers changing? Are they getting more features? Are they getting cheaper? What is the most exciting change you're seeing? Cheap is not the most exciting part, but it's actually what seems to happen in a way.

The simple debuggers actually get cheaper. So every hardware vendor or silicon vendor has their own sort of debug probe, like LPC-Link, ST-Link link and all of them do their job but they're what they are. You can improve yourself by just using something really good and if you use an ST link to download things and you use a J-Link to download things, you would face an incredible amount of time reduction with the downloading.

So no longer you can go and have coffee during that time or whatever. But what really is exciting about is the possibilities you have today with debugging. There's so many new features being introduced in the last years. On the high end, we see a streaming trace on the ETM side where you can do things like code profiling or code coverage in your target system and no longer need to do it in simulation. But you can run verification tests for weeks, for months, basically recording every single instruction you have executed in your system,

just limited by the hard drive capacity on your PC. That's really amazing on the high end. That is exciting. I can't wait until I actually have that for myself. Well, that leads me to a question. I've worked at a lot of companies doing embedded development on small arms and stuff, and thus far it's been pretty rare to have access to these tools.

What do you think the resistance is, or do you see resistance to using these tools? Because most of us seem to be, okay, we'll get a J-Link and we'll do unit tests on our desktop, but we won't do that sort of thing on device. We won't do coverage tests. We won't use trace.

Is it simply a matter of cost? Training? Or training? Training. Okay. Or knowledge. I think many possibilities that are there in debugging are not known to people. With the streaming trade things,

basically until we introduced the TradeJS Pro and the trading itself was difficult to set up. And now we have a device which can be set up in less than 10 minutes by our commercial apprentices. We tested it. So they have no technical background.

They did it in 10 minutes. What debugger did they use? Or what software works with the trace? That's Ozone. Okay. Right now it's for the streaming trace and the code coverage options trace? That's Ozone. Okay. Right now it's for the streaming trace and the code coverage options, it's just Ozone.

Embedded Studio will have it soon or has just sent it out in the release. I'm not 100% sure. So that's coming as well. And we'll definitely have other companies pick that up as well. So we're talking with Kyle so you're talking with carl we're talking with ir um at some point they will have will something be happening i'm not sure

about ir but i'm pretty sure carl will do it at some point cool so that's basically the higher end and if you talk about the um middle, so the training pluses and so on, then you have things like RTT or high speed sampling and stuff like that. So RTT is a real time transfer, which basically gives you a buffer on your target system and the trainings reach that buffer and you can do it with that buffer or whatever you want and you can do it in real time. So the most prominent solution there is printf debugging in real-time capable systems. That's the most straightforward way to do it. If you use SWO, you have such a high overhead, it doesn't really work.

Printf usually needs a breakpoint to print to the terminal. or you have such a high overhead, it doesn't really work. Printf usually needs a breakpoint to print to the terminal. But if you can have direct access to the memory, which you have as a court exams, then you can basically do Printf stuff inside real-time applications. And I really like that because I've been in closed loop control engineering in the past, and that was the one part I was missing there. It's so basic debugging, but it's incredible that it didn't work that time and now we can just do it. But there are a lot of more other things you can do with that sort of thing. So the event tracing tools you have seen recently, one of them being your own free system view,

which is free to use for people. They can instrument your code and trace every event you have for an address, you would trace tasks, which is you might trace the number of nodes or monitor the messages you have inside the system and stuff like that. So a lot of things going on, but you have to know about it and you have to um try it out yourself to really um to really make use of it because it's um things that are rarely taught right now it's hard usually when i'm working with my debugger i am trying to solve a problem in pursuit of getting a product out or getting my code finished or giving it to someone so they can use it. And so I just want my debugger to do what I want. And it's hard to allocate time to say, oh, what's new in the debugger world so that next time

I can use it? Because I don't necessarily want to learn all of these things when I'm deep in debugging. How do you convince people to take the time to learn? Have you ever tried to chase an errant interrupt? Yes. Okay, that's where you

want to have system view because then it's basically a breeze to find out. If you have an interrupt that's firing errantly, it's difficult to find out why it fires and how it fires. Once you instrument your code and have a graphical view of how your interrupts are actually firing and in which order, you can easily find out in which order they are firing and which one actually causes this interrupt. We actually solved our own.

We had one driver, I'm not sure which processor it was, but we had one driver on the USB side where we had a problem with the performance. And at some point we found out that it was triggering an interrupt, which we didn't want to have there. And we quickly found out because we used our own tool, in this case, was the system view. And we had customers who had done some configuration wrong and things didn't work right and we could show them that their hardware was actually the problem

because the hardware was firing interrupt which was definitely not caused by the software. So things like that can really save time. Is this with your high-end trace tool though?

Or is this with the RTT on your mid-level? That's actually SystemVue is basically available for chaining base. And actually SystemVue even works without

debug probe if you really want, but then you don't have the real-time option there. Then you have to write your buffer, read out the buffer, and then feed the buffer into SystemVue. That's still... Okay, that sounds interesting. And yet, I probably would have spent hours fiddling myself before

taking the hit of knowing I need to install some software and learn how to use it and learn how to configure it. Because that's not free i mean to some extent if i kind of know which interrupt is wrong and and as someone who really wants to encourage people to use the right tools how do you convince them i mean stories like that are convincing but do you find there is some way to push people to not assume that the tools aren't better than they have? Well, the only way is basically make them use the tools.

So what we do is on shows, we take people to our computers and demonstrate tools. We're currently doing some videos trying to show how easy it is and how easy it is to set up and stuff like that. So we really try to make people see what's going on there and how easy it is. That's basically one of our reasons is talking about those things and make them transfer the message. We're trying to get away from that weakness because it's been hurting us in the past. And definitely when we see the tools we have available and the tools available out there, not only from Laguerre, there's so much going on.

And at some point I had a discussion with someone and he said, well, in the end, it's not a debugger, it's a verification tool. And there's some truth in there because we don't want to wait for the bug to happen, actually. We want to squash the bug before it happens. We want to have this bug found before we deliver the software. And there are so many tools out there, the system view just being one of them, that help us achieve that.

It is hard because I need to, as somebody who charges per hour, I need to let my customers know that I'm going to be taking time away from obvious forward progress in order to make the code

more robust to verify it. I would assume specifically as a consultant, you use some set of make the code more robust to verify it. I would assume, specifically as a consultant, you use some set of standard software. So you would not create your own RTOS. You would either have created it already or you use some of the commercial options out there. You probably would use an IP stick, for example. And if you want to use a tool like SystemView,

basically you can have an instrumented version of mMOS. You can have an instrumented version of FreeRTOS. There's an instrumented version of Micrium. And it's not really hard to instrument the standard software. And many have instrumented the standard software just switching on the instrumentation and saying, okay, I'm debugging it now. It's not really a big effort. It's just standardizing on that part at some point.

So taking the time at some point and basically switch it on if you need it. That makes sense. Going back to a much earlier answer where you said one of the interesting things that's happening in the debugger world is all of these boards that have

onboard debuggers. How does that affect Seger? I mean,-board debuggers. How does that affect SEGGER? I mean, you sell debuggers and they're essentially giving them away. Yeah, basically we are also partly at fault for all these on-board debuggers. There has been a genic OB basically in 2010, I think already. And the reasoning behind it is basically people start with an eval board and the eval board manufacturers at some point realized they want to put a complete solution on the desk of the people and they don't want to have a big package of it. So if you want to have a nuclear board, a discovery board, or freedom board, or you name to have a nuclear board or discovery board or freedom board or

you name it expresso or whatever um they are small and if the debugger is basically double the size the package is going to be triple the size all of a sudden so they want to have it on board and that um yeah basically we had to follow that one. But there's also the market of people who create real systems and they don't have a debugger on board. They need one. They need a debugger. So for development projects, it's not hurting us at all. And for hobbyist projects, it's good if they use it and if they get cheap access to it, because then they get used to it. And if they do a real job, then at some point they are going to purchase professional tool.

And if we are on there and basically there are just a few eval boards where we're not on um then the chance is very high that they are going to take our product because they are used to it they enjoy the speed they enjoy um all the tools they can use um they have some experience with the tools already so they know that they are going to save time over some other solutions and so on. So for us, it's two-folded, but in the end, that's a good thing. Training people to use these debuggers that go beyond just copy over your code and flash the processor that way, but actually being able to step through, I can see how that helps you. But then there's this ST link that I can turn into a J link.

That didn't make any sense to me. And I thought it was a hack that was maybe not really ethical or maybe not right. But then I saw on your website that you're supporting this hack. For sure. It's an ST-approved hack by Zyga Engineers. So basically the old discovery boards always had the JTAG pins somewhere. And the more recent ones no longer do have it.

And at that point we needed some way to basically get trailing on there because we have customers who want to use the jailing they don't want to use the stv we said okay those customers are using our jailing already. That's probably one of the reasons ST approved that, because they don't want to lose those customers. And for other customers, with the ST-Link turned into J-Link, we opened up a whole ecosystem by Zagger. So from our point of view, it makes completely sense. So Embedded Studio, for example, right now works with training only. It wouldn't work as a nest healing right now. So to use Embedded Studio, which is free to use, unlimited for commercial, evil use, and so on,

we need the training. And that was our motivation to do it. It was very strange to me to realize that, I mean, the J-Links, they're not cheap. I mean, I've had my eyes on a bigger one. I always want one that's two up from whatever I have. And I've been working with the J-Link base for a while and looking at the pro and trying to decide

whether or not this is the year we spend that money and the trace is up there. You can simply move your ladder up. You can use our trading program and say, okay, I have this one and step up to the next one, step up to the next one, step up to the next one. Oh, I have a JTrace Pro. Great.

What is this program? Trade-in. Trade-in? Yeah, we have a trade-in program where you can send your old debugger and get a new one for a reduced price. I got a box full of them. Can I send in that?

How many do I need before I get a new car? You cannot send two debuggers to get a new one. Okay. Well, how about the TI Code Composer debugger and the Jlink Lite? Can those combine into an actual debugger? Not really. So some qualifications to this. Yeah.

You need a black box or maybe one of the old yellow boxes. Everybody now is going out to their garage. I'm sure there's one in here somewhere. Do you see that trace will become as commonplace as standard JTAG debugging, stepping through and stuff like that? Do you see it moving down market? Or will it always be kind of a extra special, more advanced kind of technique?

Depends on how much money people want to spend on their tools. Okay. Trace is more effort to get out of the CPU, even though the ETM is already a good start. But it has to set up the ETM, which is different from Silicon Vendor to Silicon Vendor. The data you get out, you have to actually link that to the code

because it's not getting you the code lines. It's a smart way of compressing data for where your program counter actually is right now. But there's some effort behind and that's making the hardware expensive and the effort on the software side a little bit bigger. So not so many

companies are actually offering a decent trace tool right now and usually the trace tools are quite expensive. Okay. And yet, it's hard for me to think back to the late 90s or early 2000s. And the idea that you could buy a $20 board with a debugger built in would have been... I mean, the reason I have those debuggers still is because they were so expensive.

There was no way I was getting rid of them, even though now they're built on to boards. So I wonder if this conversation in 15 years, if we'll just all have trace and know how to use it and it will be just a normal, oh, I know where my interrupt was because I just walked back to where it happened. That should be the way it is, right? Ah, technology moves so fast and yet not fast enough. And I think in 15 years, we were definitely talking about different things. I was working on the hardware loop thing and basically around 2000, I really would have liked a decent debugger. A simple debugger would have been great.

And there was not. So at least not one affordable for me because the Institute wouldn't purchase one thing for 10k or I think it was even more back then. And I remember when development boards were $10,000. And you would, well, I would always end up borrowing them from the application engineer for two weeks while I prototyped enough to see if this processor did what I needed it to do.

And now if a chip isn't on a DigiKey board, at least its family should be. It's kind of cool. Yeah. Do you see any other shifts like this coming up? I mean, it has changed a lot in the last 10 or 15 years. Once we have traces on all the boards, what else do you think we'll get? I think the tools like the event tracing tools, they've just started, so that's actually already a big shift.

And they will definitely evolve into something everybody is going to use because they are really a big helper. And that's going on a lot right now. I think a lot of things will more move into the verification side of things. So right now, most people talk about debugging and they try to shift it in the other direction and more into advanced debugging. So anticipated debugging is like finding a box

before a customer does and stuff like that. Well, that goes back to the verification. And even with the trace tools, you can do a different form of test-driven development. I mean, if you're tracing through and you have a Python script

and you know where it's supposed to go, you can check. I mean, find out where it's supposed to go. Find out who's using all the battery. Find out who's... Or you can write unit tests that run on the device, sort of kind of, or automated verification tests

that you have a lot of visibility into what's going on. Well, he was talking about that memory link, the RTT. That would be a great way to do on-board, not invasive, compiled-out unit tests. Yeah, I'm going to look into that. That seems like something could be very useful. What about security and debugging?

A lot of things about security. The debugging side, actually, because there are customers who actually switch off JTAG because they see if JTAG is open, my system is open, which can be the case, but doesn't have to be the case.

Depends a little bit on the silicon use and on the protection circuits used there. So there's something going on that's going to be in the market in the coming years. As a device security, there are so many things and what's quite interesting about it is the embedded industry doesn't really pick up the security things as fast as I would expect it actually. The units are all exposed to the internet because the internet has things and personal devices are exposed to the internet. And as there's not enough security in there basically it's hackable, it can be abused, it can be read out, it can be copied, whatever. And for some reason, the industry is not really

following that strat. I think it will become a lot more important as we go forward. It's already a lot more important, I think, as we're just realizing that it's a problem. Yeah, and how big of a problem it's going to be. Two years ago I had a customer and he said basically, in our country we don't need security.

We'll find out. Are they on the moon? Are they not connected to the rest of us? They definitely are connected to the rest of us but I'm not sure whether they see that they're connected to the rest of us? They definitely are connected to the rest of us, but I'm not sure whether they see that they're connected to the rest of us. That was interesting because basically they said they are producing in France, they're producing stuff that's not connected to the internet and so on.

They said, we don't need security. Well, if I produce in Germany, there's still a Chinese company creating a copy of my device. Right. And I don't want that. Okay. In the beginning, I might want to have that

because as I copy it, there are millions of devices out there. People get used to it. And at some point, I want to stop it because then they copy it there are millions of devices out there people get used to it and at some point i want to stop it because then i want to earn money well that's um yeah and yet you really don't want to have your devices out there copied free will and same time you don't want to have your devices being abused. Takes the worst case if you're looking into medical devices and the medical devices being abused, it can lead to death of the person using it.

That's something you don't want to have. You don't want to have someone tampering with your device if it's a medical device. And that's all things that's required and people start to pick it up, but that's not

nearly where we think it should be. I think even the media says it's important, but it's not really

down to all the customers out there. Still many customers who need to convince the management that they have to invest the time to create the customers out there. There are still many customers who need to convince the management that they have to invest the time to create the right concepts because the weakness about security is basically not that the tools are not there.

The weakness is that you have to have a decent security concept. And the decent security concept means that you have to look at many different aspects of the system and how this can be manipulated to do things you don't want it to do. And the most straightforward thing that many people do wrong in their concepts is actually key stored. If I store the key on my embedded device I have to make sure that nobody is able to read it out and some people say okay when I encrypt it

what they forget is if they encrypt it on the device the key for the encryption is somewhere I liked what you said about not being a tool problem because so often people approach problems they have, whether it's security or something else, by saying, oh, I just need to get this tool and it'll fix my problem or tell me how to solve it. And really the best tools can do is verify

that what you think you're doing is what you think you're doing. And if what you think you're doing is wrong, they're not going to help you. So if you have a terrible security model, yeah, your tools might tell you everything's fine within that model. But if you don't understand what you're doing, there's no tool that's going to help you except, you know, a book. All right. I can hear that your voice is starting to go, Dirk. And I do want to ask you for that final thought to leave us with.

So why don't we go ahead and do that and thank you so much for being on the show I really appreciate it and so now do you have a thought to leave us with? Actually we've been talking about debuggers and most people actually use a debugger to solve a problem. And from my point of view, it's rarely really a problem. It's just that we don't see the solution directly.

The solution at times can be found in advance. So we just need to take a step back and look at the things in a different way. And usually even at some point you find it sounds easy. It's not, definitely not. There are tools there that should make it easier. We've all spent so much time debugging. We'll definitely take any help we can to reduce that time because testing is always that part most people don't like. Cool.

That is good advice. My guest has been Dirk Ackermann, Partnership Marketing Manager at SEGGER. I want to thank Christopher for producing and co-hosting. Dirk Ackerman, Partnership Marketing Manager at SEGGER. I want to thank Christopher for producing and co-hosting. And of course, thank you for listening. My final thought this week actually is not going to be a quote. It is going to be the concept of herd immunity.

If you are familiar with this, good. If you're not, it's the idea that people who get vaccinated for the flu can protect the people who can't get vaccinated. So if you're going home for the holidays and it's early October, now is the time to get the flu shot so that you don't spread it to grandma who can't get the flu shot for some reason. So, yeah. Dirk, thank you for speaking with us. I know you're not feeling great, but you do lead to a good example for the rest of us, and we should go out and get the flu shot. What is this public service announcement? It's over now. It's over now. Thank you. put them there and do not receive money from them. At this time, our sponsors are Logical

Elegance and listeners like you.