Endianness, or the way elements smaller than a word of data are stored/retrieved in sequential bytes of memory, is usually not something software engineers need to consider except in certain situations. Endianess can become a huge issue when more than one hardware engine (processor or peripheral) may deal with the data. The issue also pops up when porting code from one execution environment to another.
ARM V7 added some facilities to work with this but care must still be taken when working in one of these situations.
For programs that execute directly from flash memory, which normally has an element size that is smaller than the native word size of the processor, code must be stored in the correct endianness format (either big-endian or little-endian) or the code may not be fetched properly by the processor. So, for example, if a program stored a value at a location in memory as a word and then the processor fetched (controller transferred) that data as individual bytes, the fetched data could end up in more than one possible order, depending on whether the system was implemented as big-endian or little-endian. Of course, if the data received by the processor is not in the order expected by the programmer, the software will likely not work very well.
An updated Application Note we’ve published, “Endianness and ARM Processors”, gets into the finer points of endianness and explains how our SourcePoint® debugger’s Target Flash Programming feature provides an easy solution. Click here to download the Application Note now.
