Endianness with RealView in board MCBSTR9

Hello everybody.

I have a rather easy question but it is making me lost a lot of time. I have the evaluation version of Keil's software.

For processing Ethernet Data Frames using a board MCBSTR9, I defined some structures in C so that I can access the data field by field. But when I tested the program I saw that the C compiler treats the data types with more than one byte as if they were stored in a big-endian way.

For example: I read the field Type/Length of an ARP Ethernet frame. It's a 16 bits field so I defined it as an unsigned short (or u16 in the ST 'standard' naming). Its value should be 0x806, but when I print it on the display it reads 0x608. However, if I cast the field to a byte array and I print the values of each byte in ascending order, I get the right value 0x806.

I'm absolutely sure that it's not a problem of printing. I've borrowed the files to use the display from the Blinky program and to work with the Ethernet port I've slightly modified the ENET files from the Easyweb example.

For example, the following code is executed inmediately after the main function starts:

// Wait until we have data to transmit...
while (!(CheckFrameReceived()));                      // Frame received

// We set up the frame to process it
// This step is necessary due to the way the "ENET" SW layer is programmed
StartReadFrame();
#ifdef DEBUG
        // Inspecting Frame

        LCD_cls();
        if (rptr->LengthType <= 1500){
                LCD_puts("Length");
                sprintf(string, "%d", rptr->LengthType);
        } else {
                sprintf(string, "0x%02X%02X", *((u8*)(&rptr->LengthType)),*((u8*)(&rptr->LengthType) + 1));
                //sprintf(string, "0x%04X%", rptr->LengthType);
                if (rptr->LengthType == 0x0806) {
                        LCD_puts("ARP Frame!!!!");
                        display_wait(5);
                        LCD_cls();
                }
                if (rptr->LengthType >= 0x0600)
                        LCD_puts("Type");
                else
                        LCD_puts("Wrong Len/Type");
        }
        LCD_gotoxy(1,2);
        LCD_puts((u8*)string);
        display_wait(5);

I get the ARP frames the computer sends to find the board's MAC address, and I should get a message 'ARP frame!!!'. Instead, what I get is the Type/Length field value interpreted is 0x0806, because I'm printing it byte by byte. If I uncommented the following line, I would get the value 0x0608, which is why the comparison in the if is not succesful.

My question is: is there any way to change this, and make the data types with more than one byte be interpreted in the correct order? I know that there are easy workarounds for this issue, but I this is only a matter of the compiler, or that's what I think, I believe this should be solved in a different way.

Any ideas? Thank you very much!