The technical field of this invention is embedded memory debug testing.
Uninitialized memory reads (UMRs) are a common issue encountered by software programmers and often times difficult to track down. There are many situations where a UMR might be encountered, but ultimately a UMR is defined as a read from a location in memory that has not been initialized.
Some scenarios which might result in a UMR are read requests that:
An example in C of the scenario described above in “Access a memory location that has been allocated, but has not yet been initialized”:
Typically when one thinks of how UMRs occur they think of a processor executing an instruction sequence. It is important to note that a UMR can be the result of a read request by any master in a system, including DMAs, and peripherals.
One approach in the prior art is to establish a ‘watch’ at various locations in memory. Once a watch is established, it is assumed that the memory locations it is monitoring uninitialized. Subsequent accesses to the watched memory locations are monitored with a ‘write’ causing the associated address to be treated as initialized. If a watch detects a read access to a location that is uninitialized, then the equivalent of a UMR is triggered.
The disadvantage of this approach is the reliance on hardware tracking the state of specific memory addresses or memory regions. This can result in a large amount of extra hardware, usually on the order of 1 register per address being watched.
An other approach known in the prior art is where reserved/unused encodings of a memory's ECC (Error Correction Codes) are used to detect UMRs. The ECCs within a memory are initialized by Built in Self Test (BIST) logic to a state that is defined to mean ‘uninitialized’. When a memory is written, the ECC will be overwritten with a setting different from the ‘uninitialized’ encoding. If a memory is read with an ECC value indicating that the memory has not yet been written then a breakpoint or interrupt will be generated. The disadvantage to this approach is that it is only functional with memories that support ECC.
The proposed invention uses a data watch point to monitor all read data cycles for a specific value that was set by debug tools. The value that is being watched for is pre-determined and represents uninitialized memory. This value is referred to as UMR_DATA_VALUE from here on.
At the beginning of a UMR debug session, all memory in a system will be initialized with UMR_DATA_VALUE. In systems where this is not practical, some subset of memory defined as part of a debug session as needing to detect a UMR is initialized with UMR_DATA_VALUE.
As part of program execution, whenever allocated memory is freed, the contents of that freed memory would need to be initialized with UMR_DATA_VALUE.
Data watch points need to be strategically deployed to key monitoring points in a system's bus topology. The data watch point monitors the read data cycles of the bus infrastructure that it is attached to. When the data watch point detects a match between the value observed during a read data cycle and the UMR DATA VALUE it triggers a debug sequence. During the debug sequence, information associated with the read data cycle is captured and then some action is taken
These and other aspects of this invention are illustrated in the drawings, in which:
The proposed invention uses a data watch point to monitor all read data cycles for a specific value that was set by debug tools. The value that is being watched for is pre-determined and represents uninitialized memory. This value is referred to as UMR_DATA_VALUE from here on.
Because this invention relies on a specific data value to represent uninitialized memory there is a possibility that this data watch point solution will detect a UMR at a location that happened to have been initialized with a value that matches UMR_DATA_VALUE. Statistically, with an 8-bit read transaction, this will happen 1 in 256 reads. With a 32-bit the likelihood is much less at 1 in -4 billion.
As part of program execution, whenever allocated memory is freed, the contents of that freed memory would also need to be initialized with UMR_DATA_VALUE.
With this invention, data watch points would need to be strategically placed to key monitoring points in a system's bus topology. The data watch point monitors the read data cycles of the bus infrastructure that it is attached to. When the data watch point detects a match between the value observed during a read data cycle and the UMR_DATA_VALUE it triggers a debug sequence. During the debug sequence, information associated with the read data cycle is captured and then some action is taken.
The type of data that is captured when a debug sequence is triggered includes: read address, initiator ID, and a timestamp. Additional data which is relevant only to specific instances of a watch point might also be captured. For instance, a data watch point deployed within a DSP might include PC and a task ID.
A debug sequence is completed with a debug action that signals a UMR. The debug action that is taken depends on the context of the data watch point that triggered, or the nature of the debug session. Examples of debug actions include: halting one or more CPUs, generating an interrupt to a processor, and generating a trace message.
Many systems support multiple sizes for read transactions with different alignments. It is desirable in such systems to use a UMR_DATA_VALUE where every byte-lane is identical. For instance, in a system that needs to support 8-bit, 16-bit, 32-bit, and 64-bit data reads, UMR_DATA_VALUE could be CCCC_CCCC_CCCC_CCCCh.