Abstract: A software error in a mobile computing device is patched in the field when an application executing on the device crashes. The usage pattern of the device determines the type of crash data that is submitted to a crash server. The crash data is compared to registration information to identify the availability of an application fix that overcomes the error that caused the device software to crash. Crash information that identifies information corresponding to the device where the crash occurred is submitted to a patch detection server. The patch detection server generates Extensible Markup Language (XML) schema based on the crash information. The application fix is located on the patch server using the XML schema and a patch identifier associated with the application fix. The device loads the application fix into memory to correct the error in the software code.

Abstract: A technique to implement software debugging capability using breakpoints includes creating breakpoints, storing them in a watchlist, and paging out a virtual address (VA) to physical address (PA) page entry in a translation look-aside buffer (TLB). When software under test is run at full speed, memory is accessed via the TLB VA to PA page translations. When a translation is missing, an exception is generated. Handling the exception includes determining if the page missing from the TLB matches a breakpoint address in the watchlist. The address and operation type are compared to the watchlist. If the operation matches the address and not the specified data, then the software under test is single stepped, the TLB page is removed and the software under test continues to execute. If the breakpoint and data type matches, then a debugger is notified and debugger action to service the breakpoint occurs.

Abstract: A technique to implement software debugging capability using breakpoints includes creating breakpoints, storing them in a watchlist, and paging out a virtual address (VA) to physical address (PA) page entry in a translation look-aside buffer (TLB). When software under test is run at full speed, memory is accessed via the TLB VA to PA page translations. When a translation is missing, an exception is generated. Handling the exception includes determining if the page missing from the TLB matches a breakpoint address in the watchlist. The address and operation type are compared to the watchlist. If the operation matches the address and not the specified data, then the software under test is single stepped, the TLB page is removed and the software under test continues to execute. If the breakpoint and data type matches, then a debugger is notified and debugger action to service the breakpoint occurs.

Abstract: Software breakpoints for code that normally executes from ROM are set by remapping a page of virtual addresses normally translated to a page of physical addresses in ROM to a page of physical addresses in RAM. This new mapping is stored in the page table and translation look-aside table (TLB). Further, the information stored at the page of ROM is copied to the remapped physical addresses of the RAM. As a result, the ROM information is stored at physical addresses of RAM, and virtual addresses of that ROM code are remapped to these RAM physical addresses. Accordingly, software breakpoints can be written for the ROM code because the code is now stored in RAM.

Abstract: A software error in a mobile computing device is patched in the field when an application executing on the device crashes. The usage pattern of the device determines the type of crash data that is submitted to a crash server. The crash data is compared to registration information to identify the availability of an application fix that overcomes the error that caused the device software to crash. Crash information that identifies information corresponding to the device where the crash occurred is submitted to a patch detection server. The patch detection server generates XML schema based on the crash information. The application fix is located on the patch server using the XML schema and a patch identifier associated with the application fix. The device loads the application fix into memory to correct the error in the software code.

Abstract: Data capture and analysis for debugging embedded systems is disclosed. On a target, there is at least one data collector, each of which publishes predetermined data of the target, and a collection manager for managing the data collectors. On a host, there is at least one viewer, each of subscribes to the predetermined data of a data collector, for processing thereof, and a viewer manager for managing the viewers. Data collectors and viewers can be added, such that an extensible data capture and analysis embedded system architecture is provided.

Abstract: Target control abstraction for debugging embedded systems is disclosed. In an abstracted hardware model, there is a non-hardware-specific debugging interface, for communication between a debugger for the embedded system and the hardware of the embedded system. In an abstracted hardware-via-software model, there is a proxy to receive commands intended for the hardware of the embedded system from the debugger, and a component within a kernel of the embedded system to receive the commands and convey them to the hardware.