| ??? 09/05/07 18:40 Read: times |
#144054 - Ave you ever looked at a "bondout" version? Responding to: ???'s previous message |
Jan Waclawek said:
Richard Erlacher said:
Given that the ICE manufacturer has little more than, perhaps, a bond-out version of the same MCU to use in his hardware, in order to stay in sync with the target hardware, how does the ICE do anything that a monitor doesn't do? Isn't it simply substituting ICE-local RAM for the target's ROM? The bondout allows the ICE to: - break execution based on direct observation of the internal buses, without need of modifying the target's binary How, exactly, would you guess that they do that? What kind of technology would they use to operate fast enough, yet stay in sync with a target system? - communicate the internal state to PC independently of code running on target; even the clock may be stopped
- log the trace - certainly a couple of other things I forgot about. It's non-intrusive as long as the software is concerned. The main concern is, that it is NOT the real hardware (mcu) to be run on the target; although the ICE-makers do everything thinkable (no wonder - for that money... :-) ) to make it as close to the real one as possible. Then, there are these modern quasi-ICEs, where a debugging hardware (such as breakpoint address compare registers and comparators, independent communication channel ("JTAG" but not necessarily) with extra hardware (e.g. RAM for the stack) hidden to the user) is built into the mcu, so you run what you debug; of course, this hardware has somewhat limited capabilities compared to the "real ICE" (Erik says, it's once in a lifetime one could make use of the extras provided by the "real ICE"). This is in the Cygnal/SiLabs, Ramtron Versas, and a few others. Certainly JTAG is utterly incapable of "real-time" anything, since a typical MCU can execute several instructions within one bit-time on the JTAG cable. Erik Malund said:
if you have a monitor, your memory map is screwed up and some interrupt is screwed up and ... is screwed up. You get what you pay for. A monitor still can prove to be useful for quite a number of things. And, monitors can be extremely flexible and can fit into places where there is no ICE available, for example. JW PS. Erik, this is a FAQ to be written (I know you started but I would like to list all the options with all the + and -). I remember we already started that in a thread maybe a year ago, but I cannot find it... Have you ever looked inside an ICE ... a "real" one, with a bondout chip? Have you ever looked at the datasheet for a bondout chip, e.g. the one from Winbond? How do you suppose they do anything at all in real time (meaning at the rate at which the target operates) when emulating on a "real" core? I've used ICE's and I've used monitors. In the early days of microprocessors, the ICE appeared to be useful. Once I learned how to use a debug monitor, the ice was gathering dust. Mainly, of course, the hardware is in the way. If I insert an MCU that has a monitor on board into a system, I can examine everything that might be malfunctioning. That's my first requirement. If I use a monitor that lives outside the memory range of the target, then the monitor doesn't foul up any of the address space. That situation is, of course, a mite harder to create, but it is common enough. I've acquired a few ICE's for different MCU's. I've never learned to like them, though. ICE's must be useful for something, but I've never made myself dependent on them. Under a non-Windows OS, if an ICE could communicate enough information fast enough, it might be possible for a PC to be helpful. I can't recommend waiting for that day, though. RE |
