trouble over trouble

thanks for your answer...

the received data from the ethernet are stored in the sdram. I wrote a small programm to see if I get the data here and yes the data overwrite my pattern. There's one ethernet register where I wrote the address for the received data from the ethernet (transmit to the sdram by dma)

At the moment I have always data abort when data are received by the ethernet - and the address of the data abort is very often within the heap size.

But I don't know why the heap size should be too small. I only read, that the stdio-lib would use a lot of heap size.

my stack ptr is:

__initial_sp                             0x00201018   Data         544  rm9200.o(STACK)

and the stack top

STACK                                    0x00200018   Section     4640  rm9200.o(STACK)
    Stack_Top                                0x00201238   Number         0  rm9200.o(STACK)

the addr of the data abort is e.g.
- 00203332
- 00206572
- 0020ACF5
- 00206563

always in the internal RAM:
INT_RAM 0x200000 0x000FFFFF (.ANY(+RW +ZI))

And moreover I know that the pointer to the USART will be overwritten very often - sometimes a data abort happens sometimes not. But this occured bevor data will be received.

thanks for your answer...

the received data from the ethernet are stored in the sdram. I wrote a small programm to see if I get the data here and yes the data overwrite my pattern. There's one ethernet register where I wrote the address for the received data from the ethernet (transmit to the sdram by dma)

At the moment I have always data abort when data are received by the ethernet - and the address of the data abort is very often within the heap size.

But I don't know why the heap size should be too small. I only read, that the stdio-lib would use a lot of heap size.

my stack ptr is:

__initial_sp                             0x00201018   Data         544  rm9200.o(STACK)

and the stack top

STACK                                    0x00200018   Section     4640  rm9200.o(STACK)
    Stack_Top                                0x00201238   Number         0  rm9200.o(STACK)

the addr of the data abort is e.g.
- 00203332
- 00206572
- 0020ACF5
- 00206563

always in the internal RAM:
INT_RAM 0x200000 0x000FFFFF (.ANY(+RW +ZI))

And moreover I know that the pointer to the USART will be overwritten very often - sometimes a data abort happens sometimes not. But this occured bevor data will be received.

If I try to write a pattern between the end of the internal sram and the stack top.

ptr = (unsigned int *)0x00206500;

If I received data packets by the ethernet, the pattern is nearly there. Sometimes I get a data abort, too, but not regularly when data are received from the ethernet; but I get nearly never a data abort, if no data will be received by the ethernet

If the address is smaller (e.g. addr = 0x00204000) than I'm not able to run the programm. The programm always stays by PLLA_loop (wait until PLL A is stabilized)...

Johannes

Is it correct, that the heap base addr is the same as the stack base addr?

Execution Region INTERN_RAM (Base: 0x00200000, Size: 0x00001298, Max: 0x00040000, ABSOLUTE)

    Base Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x00200000   0x0000000c   Data   RW           13    .data               init.o
    0x0020000c   0x00000004   Data   RW           45    .data               usart.o
    0x00200010   0x00000004   Data   RW           74    .data               retarget.o
    0x00200014   0x00000060   Zero   RW          169    .bss                libspace.o(c_t.l)
    0x00200074   0x00000004   PAD
    0x00200078   0x00000000   Zero   RW            2    HEAP                rm9200.o
    0x00200078   0x00001220   Zero   RW            1    STACK               rm9200.o

Johannes

another thing which I don't understand is, that I changed the size of the internal RAM by the linker script.

INTERN_RAM 0x200000 0x00040000

And I still get a data abort with the address 0x002FFFB.

Johannes

Changing the size of RAM in your configuration files will not change the physical memory in the processor,
or how the memory controller in the processor handles exceptions.

If you have a pointer (or return address) that points to a specific address, the processor will try to jump there without the slightest knowledge of the existence of memory.

that means, that the beginning of the heap will not change if I reduce the size of the internal RAM.

How can I find out from which code / function the data abort will caused? At the moment I only know the address of the data abort.

Johannes

What could be the problem if I write a pattern to the addr 0x00205241

for(i=0; i<100; i++)
        {

                *ptr2=0xFF7;

                *ptr2++;
        }

(the stack top is 0x00200798) and I'm not able to transmit any data by the usart? I always get a data abort (independent if there are ethernet packets).

Johannes

If I only write:

   ptr2 = (unsigned int *)0x00205241;
        *ptr2=0xFF7;

then I get a data abort to this address (caused by this write access)

But why could that be a problem, the end of the internal RAM is 0x002FFFFF

Johannes

This happens because you are violating the alignment
restrictions when reading or writing to memory. An exception will be raised if:

   read/write word32: (address & 3) != 0
   read/write word16: (address & 1) != 0

thanks for the answer...

and it is ok, if the program write data into the ram to addresses which are higher than the stack ptr address?

Which functions stored their values at this addresses? I've no own functions or variables which pointed to this address area.

Johannes

Well, that depends on your memory layout. Assuming you are using a current MDK version V3.15b, there is a new window called

Call Stack Unwinder

It works in simulation as well as in target mode (e.g. ULINK) and shows the complete call chaining and all
local variables/parameters of each call level down to
the abort handler. Using this call chain, you can find out which function caused the access to out of area memory. If such a call is unnamed, then it is most likely some library function.

yes I saw this new window called stack frames...

I've installed a function which is called if a data abort occured -> and if this happened then I only see this function and the main function.

The problem is that this error does not always happen when I receive frames by the ethernet. Sometimes I can receive 20 ethernet frames without a problem, sometimes I get 10 ethernet frames, sometimes the printf() message is not completely transmitted (but no data abort), and sometimes I get a data abort (during the receive process)...

And the addresses of the data abort are very often above the stack pointer in the internal RAM, and seldom at addresses which are not defined... I tested all pointers I have installed if they point to such a address - but there's everything ok.

the main function is very small.. I've got three global variables, one extern defined pointer and a little bit code..

volatile unsigned int Emac_Receive=0;
volatile unsigned int overrun=0;
volatile unsigned int zahl=0;
extern EMAC_pRX_descriptor p_rxBD;

Johannes

Johannes

or the function are COM1_Senchar() and fputc() (from the retarget function)...

#include <stdio.h>
#include <rt_misc.h>
#pragma import(__use_no_semihosting_swi)

extern int COM1_Sendchar (int ch);      /* in usart.c */

struct __FILE { int handle; /* Add whatever you need here */ };
FILE __stdout;
//FILE __stdin;

int fputc(int ch, FILE *f) {
  return (COM1_Sendchar(ch));
}


int ferror(FILE *f) {
  /* Your implementation of ferror */
  return EOF;
}


void _ttywrch(int ch) {
  COM1_Sendchar(ch);
}

void _sys_exit(int return_code) {
label:  goto label;  /* endless loop */
}

But I mean this function would work by nearly everyone..

Well, that depends on your memory layout. Assuming you are using a current MDK version V3.15b, there is a new window called

My memory layout is.

LOAD_FLASH 0x10000000 0x003FFFFF
{
        EXTERN_FLASH 0x10000000 0x003FFFFF
        {
                *.o (RESET, +First)
                *(InRoot$$Sections)
                .ANY (+RO)

        }
        SDRAM 0x20000000 0x03FFFFFF
        {
                phy_init.o (+RW +ZI)
        }

        INTERN_RAM 0x200000 0xFFFFF
        ;INTERN_RAM 0x200000 0x00040000
        {
                .ANY(+RW +ZI)
        }
}

Johannes