As for how this works in practice, to set a software break, the debugger would write an illegal/breakpoint instruction into memory that will cause the processor to go to an exception vector (interrupt) when the code is run and the address is hit. The debugger needs to take over this interrupt and put in its own handler to process the breakpoint.

This method has a few issues in embedded programming:
It does not work on FLASH based code (unless you want to replace the code in FLASH which is slow on most debuggers).
It does not work if mmu translation is happening like with LINUX applications as many applications share the same code address.
It does not work if a boot loader or some other mechanism overwrites the breakpoint. For example if you put a software breakpiont at the RAM address for the start of the LINUX kernel it will not work since UBoot will load the kernel to this address and overwrite your breakpoint. This is why you would use a hardware breakpoint.

Hardware breakpoints are built in on-chip. They are typically set and cleared by accessing processor registers.
Usually they branch to an exception when they are hit and can be handled in the same way as the software breakpoint from then on.

Other things the debugger needs to do on the host side:
Track the address of code and functions so that the user can set breaks at source code level.
Keep track of the number of breaks in use since all systems handle only a finite number of breakpoints.
thanks
pat

Does the software inserts a breakpoint instruction while the processor is running?? In other words…does the debugger software tries to write an instruction on the processor while it’s running to force it to halt?? And if so..how the software debugger writes to memory while the processor is reading instructions from the same memory???

First , I understand that ICE is more complicated than JTAG Boundary SCAN Test. Does functionality of the ICE cover that of another? I mean, ICE can control/run processors, directly program programmable devices, and test JTAG Cell enabled hardware logic.

Second, this is about ICE devices working with processor(like ARM)-based FPGA board (like MultiICE). ICE device must understand architecture of target microprocessor and know where JTAG cells are placed exactly in the architecture. So the ICE device can control the processor using the JTAG SCAN Chain of the processor, FLASH, RAM, and the others.

Please confirm above two questions.
Thanks for your time to answer.

JTAG Boundary SCAN Test – Uses JTAG to send and receive test patterns to devices on a board, can also be used to program devices. Is NOT used to load code or debug code on the target microprocessor. In fact does not even require a microprocessor in the circuit; can work with hardware logic (JTAG Cell enabled) only.

JTAG ICE programs FLASH by loading code to RAM on the system and causing the target micro to run this code. The code does the erase and programming of the FLASH. ICE can also do slow FLASH programming by “wiggling” address, data and control, lines from micro to the FLASH. This does not require working RAM (or code in RAM).

Hope that helps

one more thing how a jtag/ice programs the flash ?

thanks for your time to reply,