Problems using "pragma sections" with BDM in the OpenTCP project.

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Problems using "pragma sections" with BDM in the OpenTCP project.

1,941 次查看
Mr_void
Contributor I

Hello!

Hope someone can help me with my pragma problem.

 

Equipment:
I'm running Codewarrior 3.1 on a MC9S12NE64EVB using a "BDM Pod (P&E ICD)" and I use the code from the OpenTCP project.

 

What I want to do:
I would like to allocate a memory block in RAM in order to move and run a function there. Below you can see the necesary lines in my .prm-file for the allocation and my code implementation.

 

****************************************************************************************
NAMES
END
SEGMENTS 
 
  RAM_FBURN  = READ_ONLY  0x2180 TO 0x24FF;    //Memory allocation
  RAM                = READ_WRITE 0x2500 TO 0x3FFE;   /* BUFMAP = 0 (128 byte) END

PLACEMENT
       FBURN                        INTO  RAM_FBURN;
END
****************************************************************************************
==========================================================
void main(void)
{

      test_function();


#pragma CODE_SEG FBURN
void test_function(){
int a;
char tecken = 'A';
for(a=0;a<5;a++){
 tecken++;
}
 #pragma CODE_SEG DEFAULT
===========================================================
The problem:
When I use the serial monitor interface everything works exactly as I want. :smileyhappy:

 

But as soon as I switch to the BDM pod it's like a one way ticket to hell.

:smileymad:

 

The first problem I encounter while starting the Debugger is (Elf Loader) Error while writing to 2180...2380. Information: No memory at this address.

I believe that the problem is some sort of a "memory offset" problem because when I look in the "Debugging Memory Map"-window it displays that the RAM should be between 0x0000 - 0x1FFF. However if I modify this to start at 0x2000 instead, I'm able to run the code.

 

In the beginning Everything seems to work fine, the function test_function is placed at 0x2180 in the RAM area, but when I'm using the single step the code in the Assembly window seems out of place but the other windows are displayed correctly.

 

I also noticed the following line in the ne64driver.c, I've tried to modify this without any success (I also believe that modifing this file affects the Emac buffer.)

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#define RAM_START 0x2000    /**< RAM block starting address */

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

I really hope any of you can help me solve this annoying problem.

 

Thanks in advance!

 

标签 (1)
0 项奖励
回复
1 回复

506 次查看
CompilerGuru
NXP Employee
NXP Employee
you experience that the Serial monitor does Remap the RAM, so
when using the serial monitor, the RAM is always just below 0x3FFF.
Without the serial monitor, the RAM is at its reset location (check the NE64 docu).

Maybe the AN2881 helps, here's the URL:
http://www.freescale.com/files/microcontrollers/doc/app_note/AN2881.pdf?srch=1

You have two alternatives:
- either change the prm file so it uses the out of reset ram configuration (some HCS12's then don't have access to the full RAM. Not sure for the NE64).
- init the needed registers to map the ram differently in the preload command file, so the RAM gets mapped before the debugger loads the elf file.

Daniel
0 项奖励
回复