cancel
Showing results for 
Search instead for 
Did you mean: 

Different RAM area different Code?

starkeeper
Associate II
Posted on July 14, 2007 at 19:25

Different RAM area different Code?

3 REPLIES 3
starkeeper
Associate II
Posted on July 13, 2007 at 04:19

Hi,

I'm still involved in setting up my debug environment. I want to debug in external RAM, therefore I attached a SRAM to the EMI. I have tested the RAM and it works fine, without any data corruption or something like this.

Than I took the linker script from Anglia to debug in internal RAM. I adjusted the memory section, which is the only one in this case. Also I inserted some lines into my OpenOCD script to enable the EMI before loading the code. Everything works fine, until the execution of the code.

The MCU starts executing at the corrct address and a disassembly shows that there is the reset vector located. So everything seems to be ok. But the Code is faulty. It doesn't jump to the _start symbol as it should. It just steps thru the vector table and most times it jumps to undefined regions below the EMI-Area.

The disasembly of both codes, one linked with the internal RAM area defined and the other one with the EMI memory area defined, shows some significat diefferences!

So why has the code changed, and not only the addresses? And why the hell are the NOP's from the NextInst section now MOVS?

[ This message was edited by: starkeeper on 13-07-2007 07:51 ]

starkeeper
Associate II
Posted on July 13, 2007 at 04:22

Hmm, well the Code-tags seem not to work at this forum, so I attached the assembly..

[ This message was edited by: starkeeper on 13-07-2007 07:56 ]

________________

Attachments :

disas.txt : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtCw&d=%2Fa%2F0X0000000aKJ%2FRwwjqk.._CL0EOKXvCavIz9C1RejFeElx700wnjYo_c&asPdf=false
starkeeper
Associate II
Posted on July 14, 2007 at 19:25

Well I could figure out that it is not a compiler problem. It seems that the compiled binary is correct and is the same code as the code for the internal RAM.

But whenever I load the code via gdb into the SRAM it seems to get faulty. The memory dump shows after loading a different binary code than in the file on my disk.

The problem is now that my SRAM is working whenever I write to it and read from it in my code. It works even with zero wait cycles. I am able to write and read it with byte access and with word access.

I just can not figure out why it is not working correct with gdb! Is there something special about accessing the memory via the JTAG interface?