Forums

Defining the endianness for arm7 MCU

Started by Daniel April 23, 2004
Hi there, 

I am struggling with a problem on my lh75411 MCU (arm7) which concerns
the endianness. 

I observed that the endianness changes sometimes when uploading a srec
file
after reset to the MCU. I am using the following script for the
M*craigor
OCD tool: 

conn 
endian little 
CPSR = 0x13 
r13 = 0x2100 
r14 = 0x2200 
byte 0xfffe2008 = 0x01 
word 0xfffe5000 = 0x00005B3F 
word 0xFFFF1004 = 0x00000400 
word 0xFFFF1008 = 0x00000400 
download dh75411_program_sram_example.srec 
dasm 
go 

Sometimes after uploading the (little-endian) programme into the
internal SRAM, the programme is not processed properly: steping from
0x0 on shows that the branch commands are ignored and the PC simply
steps to the next address. The MCU obviously does not "understand" the
opcodes. By compiling in big endian code, the same programme works
fine (till the MCU is switching back to little endianness).

From the documentation for the lh754xx I learned that the static
memory controller assumes little endianness, and from the arm7 doc, I
learned that the processor
can run in both modes. 

My question: 
1. Is it possible that the endianness changes from reset to reset? 
2. Is there a code snippet which allows defining the endianness for
arm7?

Thanks a lot in advance! 

Daniel
On 23 Apr 2004 01:51:08 -0700, Daniel <hansch@cms.tecmath.de> wrote:

> My question: > 1. Is it possible that the endianness changes from reset to reset?
I am not familiar with the part, but usually ARM-based processors have a pin that defines the endianness on reset. It might be floating.
> 2. Is there a code snippet which allows defining the endianness for > arm7?
No. It is done in hardware. Vadim
Vadim,

I've found in the arm7 docs that the endianness can be
changed by using the co-processor register p15:

MOV r14, #0x80 ; Set BIGEND
MCR p15, 0, r14, c1, c0

I didn't try this yet, since my OCD debugger does not know
the register p15 for setting it manually!

Additionally, right after reset, the first command (at 0x00) being processed
is a relative Branch to the reset handler. If the MCUs endianness
does not fit to the endianness of the uploaded code, then the
MCU simply ignores the branch command (i.e. the PC goes to the
next address which is 0x04).

This makes me crazy!

Further ideas?



Vadim Borshchev <vadim.borshchev@127.0.0.1> wrote in message news:<opr6w1twn6y1ubid@news>...
> On 23 Apr 2004 01:51:08 -0700, Daniel <hansch@cms.tecmath.de> wrote: > > > My question: > > 1. Is it possible that the endianness changes from reset to reset? > > I am not familiar with the part, but usually ARM-based processors have a > pin that defines the endianness on reset. It might be floating. > > > > 2. Is there a code snippet which allows defining the endianness for > > arm7? > > No. It is done in hardware. > > Vadim