struct problem / usart

I installed one ptr to the array within a function (when the array is installed within this function, too -> everything works)

When I installed the array global and use one ptr within this function to point to the array -> no messages over the usart

Does the project build cleanly; ie with zero errors and zero warnings?

yes - there are no warnings or errors...

could there be a problem with to less stack size?

I mean I only install a ptr to the first element of the struct array... that's all...

Could it be that I override something which is used by the usart?? Is there a difference when I install the struct global or within a function? Is the array stored in another place within the ram-area?

tobi

ok - I tried to initialize the struct array - and get the same error... no data messages via the usart...

so I think the problem would be that the data segment array is too small - how can I make it bigger??? Or is there a better solution because the struct array has up to 50 members -> so it is not so small but I must be able to get access to this struct array from more c-functions within one c-file...

Is it possible to store the struct array within the external ram? How could I do that?

tobi

Excuse me for pointing it out but you have made a number of posts with assumptions and guesses and request for answers.

But you haven't spent any time posting any facts.

We don't know how large stack size you have. We haven't managed to figure out if you are consuming any stack space by recursive calls or by large auto variables.

We don't know how large your arreay is, or exactly how it is declared.

You haven't given a really clear description of exactly what fails, and your reasoning why it shouldn't fail.

How will people be able to help unless you clearly specify all facts about the problem?

I think the problem is the clock.... nothing works (both rs232, timer interrupts and so on...)

wow I was able to post something....

If I try to ask the state of the PMC System Clock Status Register - no bit is set (so no clock is enabled) -> but nothing happens if I do that by foot... usually that would be done in the startup code file...

Could there be a software problem? I killed something during the programming?? Os is it more likely a hardware problem?

tobi

If I try to see if the clock is ready - within my code

it fails

while ( ! (AT91C_BASE_PMC->PMC_SR & AT91C_PMC_MOSCS) );

/* Waits for the Main Oscillator to be stabilized */

But within the startup code there must be the main oscillator stable or not???

tobi

I asked you to specify all required facts about your system and your problem, or we will not be able to answer any questions.

You haven't even told us what processor you run. It seems to be an Atmel ARM chip but you are spending a huge amount of time trying to avoid facts. Why are you so against facts? Because you specifically don't want any help?

now I found the problem - it was the struct but I don't know why...

I use the AT91SAM7S256 processor - (sorry for missing this message) - I think that the problem is undependent of the prozessor.. I work with Realview MDK.

#define size 20

typedef struct my_struct {

          unsigned char Data[size];
}MY_STRUCT;

If I write Data[20] - everything is working fine - but if I use the #define, the usart and anything else which use a clock doesn't work...

It seems that the #define is not configurated when I enter the c-file with the global variable of the struct

MY_STRUCT struct_array_global[number];

number is a define too...

In a local function I only init a ptr to the head of this global array.

Maybe everybody of you coud explain me why the version with the #define size don't work...

best regards
tobi

There are many places where you may make mistakes when using #define, and we don't have access to the full code.

But you should avoid using #define with lower-case symbol names. It is common practice to always use upper-case letters for a #define, just to very clearly inform other users that they may need to look closer at the definition to be able to understand the code.

The name 'size' for a #define would also make any declaration for a parameter or local variable with the name 'size' to fail or give very unpredictable results. The code:

int copy_struct(void* p,unsigned size) {
}

would be parsed by the compiler as the broken code sequence:

int copy_struct(void* p,unsigned 20) {
}

You should also avoid the use of generic names for your defines - they are not defined in any name space, so generic names gives a large chance of collisions.

In your header file, you may write something like:

#define SIZE_OF_X 20
#define NUMBER_OF_X_ENTRIES 10

typedef struct {
    unsigned char data[SIZE_OF_X];
} mystruct_t;

extern mystruct_t myarray[];

In your source file, you may write something like:

#include "myheader.h"
mystruct_t myarray[NUMBER_OF_X_ENTRIES];

thanks for the useful information..

Is is possible that the struct is too large for the data segment? What are the steps to install the struct in the external sram?

extern mystruct_t myarray[];

Is this line of code necessary that the code is working? I only have the typedef struct definition in the headerfile.

tobi

Most programs consists of more than a single C file.

extern mystruct_t myarray[] in the header file allows other C files (that includes the header file) to know about the existence of a global variable myarry.

If your myarray variable is not expected to be known to other source files, then you should probably hide it. No information about it in the header file, and writing:

static mystruct_t myarray[NUMBER_OF_X_ENTRIES];

in the single source file where the variable should be used. This will hide the variable from the linker. To the linker, it will just be an anonymous block of memory (together with all other static variables in the same source file) without any name.

I'd have thought that you'd get an error or at least a warning if that were the case.

The questions you're asking suggest that you're very much a newbie to 'C' programming - yes?
In this case, it is much more likely to be due to errors in your 'C' than any hardware problems...