How can a program detect the uVision simulator?

and it's the same program,
You say that as if it were the solution to some problem. But it's not. It's actually a problem which you introduced into your program. Did you ever ask yourself what would happen if your simulator detection ever randomly failed on real hardware? Well, your "solution" will then turn off a whole series of important peripherals because it believes it's running in a simulator. Bad news. This is not code you want to have in your actual production executable.

I don't need to change 10+ switches and recompile it.

If you truly believe you need "10+ compiler switches" to achieve this, maybe you should get on-site help with this project of yours.

and it's the same program,
You say that as if it were the solution to some problem. But it's not. It's actually a problem which you introduced into your program. Did you ever ask yourself what would happen if your simulator detection ever randomly failed on real hardware? Well, your "solution" will then turn off a whole series of important peripherals because it believes it's running in a simulator. Bad news. This is not code you want to have in your actual production executable.

I don't need to change 10+ switches and recompile it.

If you truly believe you need "10+ compiler switches" to achieve this, maybe you should get on-site help with this project of yours.

I was writing my last message late at night in local time and I didn't think very well... Of course you could get along with only one compiler switch, but you still have to remember to change that switch and recompile the program every time you want to run it on the simulator. Not a problem? Well maybe :) But this has been bugging be for the last few days as the program is being actively developed.

Did you ever ask yourself what would happen if your simulator detection ever randomly failed on real hardware?

Can you give a realistic scenario of how the code in the second post could fail on real hardware? :) But your point still makes sense. I'll probably have to condition it out of the production build, thanks for the tip-off!

still have to remember to change that switch and recompile the program every time you want to run it on the simulator. Not a problem?

Congratulations, you're now only half a step away from figuring out why my recommendation mentioned not just compiler switches, but also multiple targets in one IDE project. One of those could conveniently called, hmm, let's see, "Debug" and differ from the other one ("Release", maybe?) by a) the detailed configuration and initialization sequence for your debugger of choice: the simulator, and b) any and all other changes necessary to configure the program for debugging, e.g. compiler switches, or reduced optimization flags.

This approach does violate an important rule in safety conscious embedded development: you debug what you fly, and you fly exactly what you debugged. But if that's truly not an option, as you claimed, then there's nothing significant left to be lost by tailoring the debug build for optimal debugging capabilities.

I am using uVision V4.60.0.0 and I haven't noticed any "multiple targets" facility in it. It does support "Multi-Project Workspaces" though, which basically means that you can edit and compile two or more projects at the same time. Presumably I could create a parallel "Debug" project and compile it along with the "Release" one. But then I have to 1) keep the two projects in sync and 2) put up with the fact that compilation now takes two times as longer (or I still have to remember to recompile).

Well, I don't know... I still haven't seen any strong arguments as to why my method may fail and why having to maintain two projects instead of one is safer and facilitates debugging.

That being said, you've sowed a grain of doubt in me. I guess I have to think more about it. Anyway, thank you everyone for your input :)

I haven't noticed any "multiple targets" facility in it.
Then maybe you haven't looked very thoroughly. Let me point your attention to the Project->Manage->Components,... dialog, and the fact it has a list of Project Targets for you to manage.

I still haven't seen any strong arguments as to why my method may fail

Actually you have. You even put the most important one right above your own description of your proposed solution. You wrote that most flash programming tools do that checksumming you intend to base your solution's design on. Someone replied that only tools for one particular brand of ARM micro controllers really do that.. So where exactly does your sudden confidence come from that this will always be the case? How do you plan on excluding the possibility that your program will, at some point, by somebody you've never spoken to, be flashed by a programming tool that doesn't follow that scheme?

Then maybe you haven't looked very thoroughly. Let me point your attention to the Project->Manage->Components,... dialog, and the fact it has a list of Project Targets for you to manage.

Wow, that couldn't be hidden better!.. But again you have to remember to switch targets and recompile the program every time you want to launch it in the simulator... Multi-Project Workspaces is probably even more convenient as it allows you to compile all your targets at once.

Anyway, thanks for the hint, I was unaware of that feature :)

You wrote that most flash programming tools do that checksumming you intend to base your solution's design on. Someone replied that only tools for one particular brand of ARM micro controllers really do that..

I thought I was clear enough when I wrote "here's my solution for LPC2xxx chips" that this solution applies to one particular brand of ARM microcontrollers :) And, I admit, it was probably a mistake to write that "most" flash programming tools do that checksumming. In fact, all of them that work with that brand and use ISP should do it.

So where exactly does your sudden confidence come from that this will always be the case? How do you plan on excluding the possibility that your program will, at some point, by somebody you've never spoken to, be flashed by a programming tool that doesn't follow that scheme?

I'm afraid I'll have to explain the boot process on the LPC2xxx...

All LPC2xxx chips (OK, all that I know of) come with a boot loader. The boot loader does two things: 1) provides an interface with flash programming software ("In-System Programming") and 2) actually executes the user program. Before execution, the boot loader checks user code validity with the very procedure I wrote in the second post. If the code isn't valid, it doesn't get executed. And what makes the user code "valid" is the flash programming software that modifies the program's image appropriately before flashing it.

That means that a program with no correct checksum just can't be running on a real word LPC2xxx, but that happens on the simulator.

Once again, to make it absolutely clear, my method is valid if:

1) it's an LPC2xxx
2) it has a boot loader

I'm not sure if 2) necessarily follows from 1), but so far I'm fine with both :)

I'm afraid I'll have to explain the boot process on the LPC2xxx...

You dare to explain something to Hans-Bernhard Broeker?

You dare to explain something to Hans-Bernhard Broeker?

I surprise myself :)