Re: Diferencia Con Software Y Hardware
Carmel Kittell
To answer your question directly software breakpoints are more flexible because hardware breakpoints are limited in some functionality and highly architecture-dependant. One example given in the article is that x86 hardware has a limit of 4 hardware breakpoints.
Hardware breakpoints are actually comparators, comparing the current PC with the address in the comparator (when enabled). Hardware breakpoints are the best solution when setting breakpoints. Typically set via the debug probe (using JTAG, SWD, ...). The downside of hardware breakpoints: They are limited. CPUs have only a limited number of hardware breakpoints (comparators). The number of available hardware breakpoints depends on the CPU. ARM 7/9 cores have 2, modern ARM devices (Cortex-M 0,3,4) between 2 and 6,x86 usually 4.
Software breakpoints are in fact set by replacing the instruction to be breakpointed with a breakpoint instruction. The breakpoint instruction is present in most CPUs, and usually as short as the shortest instruction, so only one byte on x86 (0xcc, INT 3). On Cortex-M CPUs, instructions are 2 or 4 bytes, so the breakpoint instruction is a 2 byte instruction.
Software breakpoints can easily be set if the program is located in RAM (such as on a PC). A lot of embedded systems have the program located in flash memory. Here it is not so easy to exchange the instruction, as the flash needs to be reprogrammed, so hardware breakpoints are used primarily. Most debug probes support only hardware breakpoints if the program is located in flash memory. However, some (such as SEGGER's J-Link) allow reprogramming the flash memory with breakpoint instruction and aso allow an unlimited number of (software) breakpoints even when debugging a program located in flash.
HW breakpoints are something that require support from MCU. The ARM controllers have special registers where you can write some address space, whenever PC (program counter) == sp register CPU halts. Jtag is usually required to write into those special registers.
There are a lot of advantages in using HW debuggers over SW debuggers especially if you are dealing with interrupts and memory bus devices. AFAIK interrupts cannot be debugged with software debuggers.
In addition to the answers above, it is also important to note that while software breakpoints overwrite specific instructions in the program to know where to stop, the more limited number of hardware breakpoints are actually part of the processor.
Justin Seitz in his book Gray Hat Python points out that the important difference here is that by overwriting instructions, software breakpoints actually change the CRC of the file, and so any sort of program such as a piece of malware which calculates its CRC can change its behavior in response to breakpoints being set, whereas with hardware breakpoints it is less obvious that the debugger is stopping and stepping through certain chunks of code.
Software breakpoints are set by replacing the opcode of instruction in RAM memory with breakpoint instruction. These can be set only in RAM memory(Flash memory is not feasible to be written) and are not limited.
While hardware breakpoints use a register of the CPU to implement the breakpoint itself. That is why the hardware breakpoints are much faster. And that is why we need software breakpoints: hardware breakpoints are limited to the processor number of registers dedicated to breakpoints.
Compare that to regular breakpoints, where at least the software implementation injects an int3 instruction at the breaking point and lets the program run, so you only pay overhead when a breakpoint is hit.
Hardware Breakpoints are implemented using the DRx architectural breakpoint registers described in the Intel SDM. They have the advantage of being usable directly at reset, being non-volatile, and being usable with flash or other read-only memory. The downside is that they are a finite resource. Software Breakpoints require modifying system memory as they are implemented by replacing the opcode at the desired location with a special instruction. This makes them an unlimited resource, but the memory dependency mean you cannot install them prior to a module being loaded in memory, and if the target software overwrites that memory then they will become invalid. In general, any debug feature that must be enabled by the debugger does not persist after a reset, and may be impacted after other architectural mode transitions such as SMM entry/exit or VM entry/exit. Specific examples include:
CPU Reset will clear all debug features, except for reset break. This means for example that user-specified breakpoints will be invalid until the target halts once after reset. Note that this halt can be due to either a reset-break, or due to a user-initiated halt. In either case the debugger will restore the necessary debug features. SMM Entry/exit will disable/re-enable breakpoints, this means you cannot specify a breakpoint in SMRAM while halted outside of SMRAM. If you wish the break within SMRAM, you must first halt at the SMM entry-break and manually apply the breakpoint. Alternatively you can patch the BIOS to re-enable breakpoints when entering SMM, but this requires the ability to modify the BIOS which cannot be used in production code.
Hardware breakpoints are limited in number and utilize specialized hardware features for faster performance. They are often used for low-level debugging tasks. On the other hand, software breakpoints can be set at multiple locations and are more versatile, making them suitable for high-level code and applications. However, they might be slower due to the additional processing needed to handle the breakpoint interruption.
I did not spot the difference between a software and a hardware watchpoint. I read that a software breakpoint (not watchpoint) replaces an instruction by an incorrect instruction to trigger an interrupt (and then stop the program), and that hardware breakpoint put the address of the instruction to stop at in a register and compares it to each executed instruction.
However, I am reading in the documentation of watchpoints that "GDB does software watchpoint in by single-stepping your program and testing the variable's value each time", which is basically the definition of a hardware watchpoint to my understanding.
A software watchpoint is implemented by single-stepping the program and checking the variable's value every time control returns to the debugger. This is extremely slow, since it involves multiple context switches for every instruction executed in the program under test.
A hardware watchpoint puts the address of a memory word to watch in a special debug register. The CPU checks every memory write to see if it's targeting the address in the register, and if it is, it interrupts the program under test and returns control to the debugger. The program under test doesn't have to be single-stepped, so this is much faster, but there are usually only a few of these special debug registers, so you can only have one or two hardware watchpoints at a time.
You might be confused about this because "single-stepping the program and checking [something] every time control returns to the debugger" sounds similar to the description you have heard for hardware breakpoints, where the CPU checks on every instruction fetch whether it has reached the breakpoint address. But with a hardware breakpoint it's the CPU doing the checking, not the debugger, which is orders of magnitude faster. And so also with a hardware watchpoint.
You might already know that different crypto wallets offer different levels of security. For example, software wallets- those that connect to the internet- are inherently less secure than hardware wallets, which keep private keys offline. However, did you know that the way you use your hardware wallet impacts its security?
Put simply, a hardware wallet is a physical device that stores your private keys; the ones that control your crypto account. While a hardware wallet can connect to your phone or computer, it actually keeps your private key in an isolated environment and signs transactions offline. This keeps your private key safe from online threats and scams.
For each blockchain asset, you can create multiple, separate accounts. Each of these is isolated, and not impacted by anything that happens to the others. The result? If you make a mistake and sign a malicious smart contract with your active Web3 wallet, the rest of your assets will remain safe.
Now, I'd like to move this and get rid of software serial and use the built in USB/serial connector to connect this device. By using this, I'm not able to establish the the connection with the device. By debugging it looks I'm sending out data, but the device does not reply to the arduino.
Since it used to work fine, I assume you connected to the external device by wires from the declared software serial pins. You should therefore get a result by using the same wires from the declared hardware serial pins D0,D1.
I'm not using D0,D1, but the usb connector itself, with a USB cable. I also tried to connect this USB to a PC and monitor the USB port: I see the command I send from arduino coming in.
Now, by typing a doubt came in my mind....should I care about the TX/RX wires, may be I should switch them? I don't think so, since on the PC it works...
(for uno/mega) The TX and RX lines of the hardware serial are connected to pins 0 and 1 (for most Arduino boards, at least). These are connected (through a resistor) to the TX and RX lines of an on-board USB-serial adapter. The USB D+ and D- lines from that are connected to the USB port.
(for leo/micro) The USB is connected to different pins on the microcontroller than the serial pins. The hardware serial is called Serial1 ("Serial" is a virtual USB serial port, it can only be used to act like USB-serial adapter to a USB host)
The only things that can be plugged into the USB port and be expected to work are a USB host device like a computer (which will see a serial port), or +5v power (ex, from USB phone charger or something).
d3342ee215