Why are words in reverse order when reading from a flash?
Short answer:

You are using OpenOCD in LE mode when your CPU runs on BE  (or vice-versa).

You have to specify the correct -endian switch for the target command in your OpenOCD configuration.

Longer asnwer:

Where is the endianness mismatch?

Regardless of endianness, the data is being read from the flash one chip_bus_width bits at a time, in this case 16bits. The order and width (apparently 32) in which the nibbles are sent serially over the JTAG bus depends on the CPU endianness and OpenOCD has no way (without interference) to guess this if the particular CPU can run in either mode (like MIPS or ARM cores can).

It is the CPU itself that is performing the actual read operation, commanded by the TAP controller. This would not be the case if poking the flash using boundary scan.

For both mdw or dump_image OpenOCD commands, your 4 bytes will be reversed if your OpenOCD has a mismatching endianness (-endian) setting.

Endianness and byte sequences, or strings

As stated in some comments, C strings and byte arrays will always appear in-order when inspecting the memory in 1 by 1 increments, and thus should appear in-order if we dumped that memory into a file. That is part of the ANSI C standard, and set in stone by how pointer arithmetic works:


  When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand.  If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integral expression.


Increasing the address by one we always get the next-in-sequence byte (or char in a string), regardless of the endianness. It cannot be said more clear: Endianness does NOT affect how C-Style strings are stored.

Hex dump at address 0x000000e0 of a printf("Hello, world!");:

C object code, compiled for big endian (mips-gcc -EB):

  48 65 6c 6c 6f 2c 20 77  6f 72 6c 64 21 00 00 00  |Hello, world!...|


C object code, compiled for little endian (mips-gcc -EL):

  48 65 6c 6c 6f 2c 20 77  6f 72 6c 64 21 00 00 00  |Hello, world!...|


Integers (and bigger numbers) in the other hand, are stored in the byte order of the particular endianness, and examining an integer number in RAM or in the flash (or in a dump file, etc.) byte by byte, will yield different sequences for BE or LE, very loosely related with the actual issue.