set a breakpoint on the nop

(There is this thing the software engineers have about "freezing time" when the main returns. When that happens, I can't debug while the periodic interrupt is running. I'm forced into the antique method of stopping every time I want to change 1 byte of the input data, or look at the output data. I was hoping I would not have to totally re-engineer the development system, as I did for the 6808 and the 65816.

I want to write a code segment that calculates, and then return to the debugger to look at the results
plain vanilla

The program stops all right at the breakpoint, but the interrupts are stopped! (I don't know if the timers are stopped, the interrupts, or both).
everything stops, how else would anyone be able to see what was how at the breakpoint
If I resume at the NOP and allow the program to execute the ZOT: JMP ZOT, the interrupts start up. I want to have the debugger running while the interrupts are also running.
running??? the interrupts do not stop when the debugger is 'running'
(There is this thing the software engineers have about "freezing time" when the main returns. When that happens, I can't debug while the periodic interrupt is running.
debug???
I'm forced into the antique method of stopping every time I want to change 1 byte of the input data,
your code, not the debugger is supposed to do that.
or look at the output data. I was hoping I would not have to totally re-engineer the development system, as I did for the 6808 and the 65816.
WHY, as stated above there are methods

Is the "freezing" of interrupts occur in the "2 wire interface" in the chip, (in that case I'm screwed) or can I hack it to allow running?
when you break on a breakpoint eveything stops; how else would anyone be able to see what the state of variables etc was at the breakpoint.

State what you want/need (NOT as "interrupts running while stopped at a breakpoint") and, most likely, one of the methods known to someone will work for you.

Erik

I am being tasked at work with building a system which analyzes vibrations with a digital filter. I need to be able to tune this filter while the signals are applied.

(Included with the Lynx robot kit were 4 PIC processors, combined with a PC were required to get the robot to walk. I got 1 6808 8MHz processor to do all of that, with lots of pressing time left over.)

What this means is that you need some additional interface software to expose the variables you want to examine. A simple communications protocol that allows a PC to poll the hardware for specific variables. It could be extended to allow writing to those values as well.

An interface such as this for communicating critical data to and from a robot seems like a "really useful thing". Consider spending the time. You won't regret it.

The system configuration should allow removing these limitations to allow real-time code debugging.
this is NOT a 'limitation', it simply is that the debugger only do debugging and if that surprises you then .....

Erik

It seems that you have locked yourself into a very nonstandard way of 'debugging' (note the quotes) and expecting the manufacturers to adapt to your way instead of the way of 99% of the population is not reasonable.

Furthermore, it not more complicated to enable this feature. Somebody went to a lot of trouble to insert this limitation.
I doubt that very much. Just visualize how much the timing of the running code would be screwed up if a 'debugger' at random times (as far as the running code is concerned) stopped the uC for a brief time to e.g. change a value. The value you read as a result of your tmer interrupt would be skewed, the UART transmission would be skewed ....

I would be interested if you represent Silicon labs or are a user of development systems, and what type of experience you have. If you are interested, I can show many systems which I have designed, eliminating a whole bunch of hardware with a single controller chip, and eliminating "cross-coupling effects" (such as a spurious lamp flikering on a lamp dimmer while signals are being sent to it). These systems were developed with simple DOS based tools. The tools did not have "arbitrary" limitations (and they also did not interfere with "conventional" debugging methods.

I fear that the "limitations" are built into the "C2 interface" hardware (if not, I might write my own driver).

If you are interested, I can show many systems which I have designed, eliminating a whole bunch of hardware with a single controller chip,
So have I. If you want to show your stuff, OTHER THAN circumvention of debugging standard methods, go ahead.

ONCE MORE: the patching values while running is NOT debugging, it is an optimization.

Erik

bpark1000,
Your examples are interesting and I commend you on taking the time to make your point. I do take issue with your example to some extent however.

Yes, you do not have to stop the engine to make an adjustment to the fuel/ air mixture but I don't agree that this example is applicable.
1. The engine is designed to have a fuel interface that is independently adjustable while the engine is running. On the other hand the "debugger" is not designed for non-intrusive adjustment of memory parameters.
2. If you wanted to examine the state of the piston rings you would be obliged to stop the engine. In this case the "debugger" IS designed to stop the processor in its tracks and allow examination of just about anything you want.
I used quotes around debugger above because the issue really isn't so much the debugger (software) as it is the hardware interface (JTAG/ C2). I haven't used every processor known to man but I do know that some processors are designed with hardware support for a certain amount of non-intrusive (or minimally intrusive) access to internals while the processor continues to execute code and run the peripherals. Can you imagine keeping the PWM's alive while you change the value of a watch variable and observe the effects in real time? I think this is exactly what you wish for - and it's available on some processors (TI DSP for example). There's additional hardware on the debug side that cycle steals/ has dual port RAM or something (don't really know exact mechanism) that enables this.

Silabs C8051Fxxx do not. Hence my suggestion to roll your own interface via a comm channel. I don't buy the "I need to make a million of these for it to be worthwhile" argument either. I have never regretted taking the time to enable some form of user interface into my product designs regardless of the market demand/ projected sales quantities. The added value always paid for itself.

You speak of designs you've worked on where the kind of interface you describe was made part of the product (non-flickering lamp dimmer). Reread what you wrote. You "designed" these things with that capability. The JTAG/ C2 interface into a '51 core is something fairly new to the 51 market and Silabs has done a good job with it. Historically one had to have an expensive ICE to enable breakpoints and expose internal states on demand. Even the ICE days didn't see the kind of non-intrusive on the fly access that you describe. That takes extra hardware which = $$$. Silabs designed the debug interface in such a way to enable many of the typical debug features commonly found on legacy equipment, namely breakpoints and internal register access read/ modify/ write. What we don't have is trace capability and more complex breakpoint triggers (Boolean logic). But somehow after 25 years of writing '51 code I've managed without. Probably due to those extra software interface routines I wrote.

I just don't think leveling criticism at Silabs for design choices they made in the debug hardware interface is a productive effort. Neither do I think the design limitations are at all arbitrary, but that's just my opinion. Ahh, everything here is just my opinion and I don't want to start nor continue an argument. I would hope that comments on this forum can be classified as either useful or not. Nothing else. Ignore the ones that aren't.

With an external ICE the opportunities for "fancy stuff" add cost to the hardware in the ICE (look at the price for the fancier ones). For SIlabs, however, whatever is inside the chip to allow emulation is an additional cost for each and every chip they make

Thus I think that cudos to SIlabs are in order.

bpark1000 seems referring to debug monitor, like Keil MON51 or ISD51, whose code is integrated into the target source code, or FLASHed separately on the program ROM. Usually, debug monitor communicates with PC debugger application over serial line. Debug monitor regularly steals "CPU time" from the target application to communicate with PC debugger app.

SiLabs MCU applies on-chip debug circuitry, which works as micro ICE. It is more recent technology than debug monitor. It has several benefits compared with debug monitor, but also some weakness, as discussed on this thread.

He may be better to back to debug monitor for his purpose.

just a note: a "debug monitor" is far more intrusive than an ICE.

If I were to design such a thing, I would run a periodic interrupt synced to a multiple of the line frequency, and generate the triac firing pulses. The only "error" would be the interrupt latency, which is a few microseconds at most, and independent of what is being received.

Regarding "checking the rings of an engine while it is running", you don't do that because the laws of physics. If this limitation were "not necessary", it would certainly be better to be able to do it without a teardown.

Regarding the adjustment of the mixture, it is adjustable because the engine maker would have to go to extra trouble (put in interlock, etc.) to prevent such an adjustment.