3 ms·

I wonder if there's a specialized debugger that injects random faults into your code while its running (e.g. flipping booleans or IO to peripherals). Not just f

I wonder if there's a specialized debugger that injects random faults into your code while its running (e.g. flipping booleans or IO to peripherals). Not just fuzzing the inputs to the program, but fuzzing the contents of memory and registers as routines run. You could set the fuzz rate at different levels to detect different kinds of errors (e.g. maybe one error happens frequently but another requires a timer to tick up to a certain level before errors can affect it). EDIT: Thinking about this a bit more, for messing with registers, you probably need specialized hardware or you need to intercept the data on the way to the register.

bjackman 11y ago
You could do this with an emulator I'm sure. At my company we have fairly high-fidelity models of the hardware we use/develop which could probably include on-chip peripherals in the things fuzzed. Also I guess in irradiated environments you use very simple hardware (no caches, MMUs, complex memory bus/controller) so that would make it more feasible. Would probably be really fun to develop! Edit: if you had the resources maybe you could even fuzz simulations of the RTL. Our systems take about a week to boot Linux on simulations but I guess that would drop dramatically for simpler MCU systems.
- SapphireSun 11y ago
  That does sound like an incredible start. I fear that for the kinds of applications we're talking about speed could be an issue. For instance, if the system has to respond to events it can't control, queues of events can build up or things that are likely to be synchronized might not be etc. I feel like in many situations, you'd want to run at full speed for official tests though early testing could use an emulator. Of course, if you're emulating a much slower hardware as you mentioned, the test is more realistic. ;)
  - bjackman 10y ago
    Ah the timing thing is not actually an issue because you simulate or emulate the entire system, including timers and even the PLLs that drive them. There's a globally consistent timeline. Of course this places constraints on the things you can simulate (e.g. networking is out the window).

bjackman 11y ago

You could do this with an emulator I'm sure. At my company we have fairly high-fidelity models of the hardware we use/develop which could probably include on-chip peripherals in the things fuzzed. Also I guess in irradiated environments you use very simple hardware (no caches, MMUs, complex memory bus/controller) so that would make it more feasible. Would probably be really fun to develop! Edit: if you had the resources maybe you could even fuzz simulations of the RTL. Our systems take about a week to boot Linux on simulations but I guess that would drop dramatically for simpler MCU systems.

SapphireSun 11y ago
That does sound like an incredible start. I fear that for the kinds of applications we're talking about speed could be an issue. For instance, if the system has to respond to events it can't control, queues of events can build up or things that are likely to be synchronized might not be etc. I feel like in many situations, you'd want to run at full speed for official tests though early testing could use an emulator. Of course, if you're emulating a much slower hardware as you mentioned, the test is more realistic. ;)
- bjackman 10y ago
  Ah the timing thing is not actually an issue because you simulate or emulate the entire system, including timers and even the PLLs that drive them. There's a globally consistent timeline. Of course this places constraints on the things you can simulate (e.g. networking is out the window).