How can a program detect the uVision simulator?

Need to run "the same" program? You aren't if you are completely switching what code flow your program takes. If you run different code lines in the simulator that's the same logically as running a different program.

And changing 10 switches? Why? Too quick to just change one?

#define SIMULATION 1

And that can be supplied on the command line in the project file, so no need to even change that parameter - you just switch active target.

Need to run "the same" program? You aren't if you are completely switching what code flow your program takes. If you run different code lines in the simulator that's the same logically as running a different program.

And changing 10 switches? Why? Too quick to just change one?

#define SIMULATION 1

And that can be supplied on the command line in the project file, so no need to even change that parameter - you just switch active target.

Save yourself lots of grief and continued nonsense responses. Invest in a ulink.

If you run different code lines in the simulator that's the same logically as running a different program.

Not exactly. A program may take any branch of execution depending on its input, but it's still the same program :) A different program in my case has all its variables/functions at different addresses. This may happen if the same source is compiled with different switches, and it's important to debug the same program, because some hard-to-detect errors (like buffer/stack overflows etc) may manifest themselves with one memory layout and not with the other.

And that can be supplied on the command line in the project file, so no need to even change that parameter - you just switch active target.

As I said, I wouldn't have to switch targets at all if I could debug using ulink or something, but since I can't, I have to do it too often and it buggers me. So it goes :)

Invest in a ulink.

For those who don't read: "I cannot use any of the debug adapters due to the specifics of our device".

You have never told us what that specifics are.

Neither have you told us exactly what peripherial simulation you are missing.

But anyway - you haven't given one single reason why it would be a problem to program a specific memory cell by the debugger script - the script that is unique in that it is only used when you debug your code. Of course with the disadvantage that you then release a real program with mirror functionality that gets activated by the state of that memory cell potentially making havoc of a real, live, installation.

By the way - the normal setup is that you don't need to do anything extra to get the tools to recompile your code when you switch target and wants to start debugging. So it's a minimum number of steps to switch target and then have a go at debugging.

... you haven't given one single reason why it would be a problem to program a specific memory cell by the debugger script ...

Well, because it wouldn't be a problem! It's sad if you have the impression that I'm rejecting this method out of hand. Actually, this is a good method, arguably better than mine. I just need some time to think which one I'll be using...

-> if I could debug using ulink or something

I am quite sure that, many persons involved in this thread, are embedded experts, they are good at HW/SW and many other fields. And the most important, one of them is very familiar with NXP LPC23xx. So, if it is not confidential, it would be nice if you can provide Why/Why-Not.

So, if it is not confidential, it would be nice if you can provide Why/Why-Not.

Well, it was the choice of our hardware engineers :) I'm not sure, but it has something to do with the size of our device and their not being able to find room for the connectors on the boards :) As a matter of fact, we have two LPC chips on one board and more on others, and we can't even program them separately. We communicate with one of them via CAN and it in turn programs the others using ISP...

When there is lack of room for a connector, it's still often possible to just get a few test points on the board and then you manually solder wires to get a debugging interface. With good solder skills, the test points can be made very small and very close together.

So in the end, I find it very strange to not be able to make the boards capable of JTAG-debugging.

But there is another, very easy, option - solder a JTAG interface directly on the processor pins. Spend 30 minutes and you have a board with JTAG debugging. Way better than simulation and you can finally debug real code without strange code stubs that you wouldn't want in a final release version.

Alright. Just in case someone is still interested in the topic, I'd like to offer a working cross-platform example of how the simulator can be detected using a debug script. Kudos goes to Chad Clendening and Per Westermark for the idea.

This code works on both the ARM and the 8051 simulators, with slightly different debug scripts. I now don't have all the necessary hardware to test the code on it, but I hope it works on it just as good :) Anyway, I would appreciate it if someone would check that out :)

/* sim-detect.c */

#include <stdio.h>
#include <string.h>

#if defined(__arm__)

/* This is here only to print a message over UART. In the IDE it will show up
   in a Serial Window. */

#include <lpc21xx.h>

#define VPB_CLOCK 12000000
#define BAUD_RATE 9600

int sendchar(int ch) {

        while (!(U0LSR & 0x20))
                ;

        return (U0THR = ch);
}

/* ------------------------------------------------------------------------- */

int getkey(void) {

        while (!(U0LSR & 0x01))
                ;

        return U0RBR;
}

/* ------------------------------------------------------------------------- */

struct __FILE {
        int handle;
};

/* ------------------------------------------------------------------------- */

int fputc(int ch, FILE *f) {

        return sendchar(ch);
}

/* ------------------------------------------------------------------------- */

void _sys_exit(int return_code) {

        for (;;)
                ;
}

/* ------------------------------------------------------------------------- */

#elif defined(__C51__)

#include <reg51.h>

#endif

/* Attention! These memory address values were chosen for demonstration
   purposes only. They may be incompatible with your particular memory
   layout. */

#if defined(__arm__)

#define SIM_DETECTOR_ATTR       __attribute__((section(".ARM.__at_0x40000000")))

#elif defined(__C51__)

#define SIM_DETECTOR_ATTR       _at_ 0x30

#else

#define SIM_DETECTOR_ATTR

#endif

volatile unsigned char sim_detector SIM_DETECTOR_ATTR;

int main(void) {

        /* set up UART0 to see the detection message */

#if defined(__arm__)

        PINSEL0 = 0x00000005;
        U0LCR = 0x83;
        U0DLL = (VPB_CLOCK/16/BAUD_RATE) & 0xFF;
        U0DLM = ((VPB_CLOCK/16/BAUD_RATE) >> 8) & 0xFF;
        U0LCR = 0x03;

#elif defined(__C51__)

        SCON  = 0x50;
        TMOD |= 0x20;
        TH1   = 213;
        TR1   = 1;
        TI    = 1;

#endif

        sim_detector = 0x55;

        if (sim_detector == 0xAA)
                puts("SIMULATOR DETECTED");
        else
                puts("SIMULATOR NOT DETECTED");

        return 0;
}

The debug script for the ARM:

/* debug-arm.ini */
signal void sim_detect(unsigned long adr) {
        unsigned char val;
        while (1) {
                /* wait for write access */
                wwatch(adr);
                /* read value */
                val = _RBYTE(adr);
                /* uncomment the line below if you want to see sim_detector values */
                // printf("sim_detector = %X\n", val);
                /* change value */
                val = ~val;
                /* write value back */
                _WBYTE(adr, val);
        }
}




sim_detect(0x40000000);

The debug script for the 8051:

/* debug-c51.ini */
signal void sim_detect(unsigned long adr) {
        unsigned char val;
        while (1) {
                /* wait for write access */
                wwatch(adr);
                /* read value */
                val = _RBYTE(adr);
                /* uncomment the line below if you want to see sim_detector values */
                // printf("val = %X\n", val);
                /* change value */
                val = ~val;
                /* write value back */
                _WBYTE(adr, val);
        }
}

sim_detect(D:0x30);

By the way - never let hardware engineers run the show all by themselves. Always make sure that there are one or more skilled sw guys involved, and that it is 100% clear that the total quality of the product depends on the ability to test both the hardware and the software. And that a JTAG interface isn't just an optional method of programming the processors but an excellent way to validate the prototype hardware by allowing the pins to be wiggled etc.