Time to cancel the simulator?

"you evidently only work with hardware that has complete and accurate specificatins"

This can be a significant issue.

I had one project where I implemented the full software in N hours. Then I had to spend 5*N hours to implement workarounds for bugs in the middleware. When reporting bugs, the company in question claimed there were no bugs - even when supplied with test code repeatable showing failures.

Then when middleware 3.0 or maybe 4.0 was released, I noticed that trace output indicated that the workarounds did not trig anymore - so I could spend two days removing workaround after workaround. The middleware without bugs had suddenly started to function as their documentation claimed - but without any release document ever admitting to any fixes. All I know is that the company who developed the middleware had got at least one new developer on their team - I can only guess that this was the magical difference.

Anyway - all methods of simulation are good. Options are always good.

"you evidently only work with hardware that has complete and accurate specificatins"

This can be a significant issue.

I had one project where I implemented the full software in N hours. Then I had to spend 5*N hours to implement workarounds for bugs in the middleware. When reporting bugs, the company in question claimed there were no bugs - even when supplied with test code repeatable showing failures.

Then when middleware 3.0 or maybe 4.0 was released, I noticed that trace output indicated that the workarounds did not trig anymore - so I could spend two days removing workaround after workaround. The middleware without bugs had suddenly started to function as their documentation claimed - but without any release document ever admitting to any fixes. All I know is that the company who developed the middleware had got at least one new developer on their team - I can only guess that this was the magical difference.

Anyway - all methods of simulation are good. Options are always good.

Options are always good.
exactly.

I 'never' use the simulator, but if I have some heavy crunching non-I/O stuff, I do.
I 'never' use printf debug, but when there is an issue that show up once a month at a customer site, I stick in a printf so the customer can report
I 'never' ... ,but...

I'm actually using printf() debugging a lot.

I get information without stopping any real-time code and wrecking the interaction with timed operations.

And I normally always have enough CPU cycles and flash space that I can ship with trace functionality in place. Some few lines always enabled. Some possible to turn on/off on command.

It's nice to be able to sign in to a live unit out in the field and look at performance statistics etc.

Printouts might be very much 1980 but they just happen to work very well. It's often enough with a very minor hint to be able to visualize what a unit is doing and why. Especially since most issues tends to be caused by incorrect configurations.

Or we know what the hardware does, and can validate and test enough that a ROM'd boot loader is actually going to function out of the gate, or the library functions do what they are supposed to on any ARM7, ARM9 or CM3, etc.

The idea that the software devs get to *** around and cause the SoC IP to be respun multiple times is alien, yes.

Perhaps you should focus on why your documentation is incomplete and inaccurate.