GT60 on 13192-EVB Help needed

[behradd]

Hi,
Im programming the 13192-EVB board which has the GT60 processor using codewarrior and hiwave which comes with it. I have written my code, it compiles without errors and seems to work fine until at some point during the main loop it goes off into random registers, sometimes it gets stuck with FFFF,STX the only thing showing up on the assembly window of hiwave, or at other points goes off into a BRSET series of loops and doesnt come out unless i reset the target and and restart the program, I have tried many many different ways of trying to figure out what the problem is but for the life of me cant seem to find a fault.

Any suggestions on what the problem could be, if any has encountered it , etc I searched the forum didnt find any answers.

Any help would be very very appreciated im working against a uni deadline so every second counts.
Thanks again for any help

[behradd]

Thanks again for replying....

I suspected that might be the case, but how would I go about fixing this??

[JimDon]

Well, one thing you can try is make the stack huge and see if it helps. If it lasts longer then dies, at least that is a clue.
If you can, carefully step thru the code and look at pointers - doing this some times makes you see something.
Make sure you test for possible null or uninitialized pointers.
On interrupt handler make sure you are acknowledging the hardware interrupt source on all code paths.
Do you use recursion at all? Double check that if you are.

Try commenting out sections of the code and see if it goes away. I have found out bugs this way, dividing the code in half and then in half and so on. If you can disable a function and it stops, at least you are close.
Drink lots of coffee - it could be a long night :--)

If you narrow it down to something reasonable, you could post it here, but I have nothing with 13192 hardware on it.

[bigmac]

Hello,

You have not said whether your code is written in C or assembler.  If written in assembler, there might be some of other things to check.

Assuming the use of C, you will quite likely need to check the actual stack usage as the program is run, perhaps using full chip simulation.  The usual method is to initialise the RAM block allocated to the stack, by writing a constant value, or a distinctive pattern, into the RAM block.  By periodically halting the program and examining the RAM contents, the lower reaches of the stack should still contain the initialised pattern.  If not, stack overflow is probably occurring, and the stack size will need to be increased until you can still observe a "reasonable" amount of the initial pattern after testing.

Do you have any large arrays declared as local variables?  These are likely to consume copious amounts of the allocated stack.

Regards,

Mac

Message Edited by bigmac on 2008-03-28 01:56 PM

[behradd]

Hi,

Thanks for your reply,

Im using C as the language and as im using quite a few pointers and arrays and also 3 of my local variables  are arrays in the program, this could be the problem indeed.

Sorry to sound like newbie, how would I get rid of the stack overflow?

[JimDon]

First, look in the prm file and see how big you stack is (stacksize parameter).
Ar these arrays declared as local variables? If so you may be overflowing the stack.

[behradd]

yes ive declared them as local variables.

Looking at the bootloader prm file,
the App_stack_ram is 0x0101 to 0x02C0;

so increasing this may get rid of the problem???

Thanks again

[JimDon]

Local variables are created on the stack.
You have 447 bytes of stack.

Do the math - how big are the the local variables?

[behradd]

Hi again,

the trouble is when i try to change the stack size in the prm file the program gets stuck in the Crt0.c file and specifically in the Init() function  when its trying to zero out RAM area where data is allocated. So the program doesnt even get to my code any more.

Thanks for any help ,
B_

[JimDon]

Post your PRM file or a link to it (preferred).

[behradd]

ive attached the file to this reply (sorry cudnt get a link fast enough).

Many Many Thanks for your replies.

[behradd]

Ive noticed that when putting the stack size back to the original, it seems that going through the code line by line while its executing, it seems to go through the main loop once but on returning to the top of the loop to execute again it goes off into random territory with FFF STX ,x or BRSET territory which is random behaviour.

[JimDon]

In this main loop, do you call these functions with large locals?
Step thru each function and look at the sp.
Also examine the map file to get idea of where things are located.


Also, the project.prm file seems to indicate a larger stack.
Which prm file is used for linking your project? As I said I do not have this board and I am not familiar with software that is used for it.

[behradd]

Ive tried both prm files, tried it with one removed it and re tried with the other one, same problem occurs.

I dont think im using large locals when calling the functions.

wot do u mean by sp?

ive gone through the code line by line again and same thing occurs goes through the loop once and then it gets lost when attempting for the second time,

I cant think of wot else to try...

Many Many Thanks for your replies.

[JimDon]

The sp register is the stack pointer.
Well, it sounds like you are in way over your head here. If you are unfamiliar with the SP register, then most of the advice I have given it probably not going to be too much help.
I think you should stop and take some time to review the basics of how processors work.
At least google "stack pointer" and read the wiki on it.

[behradd]

thats absolutely my mistake im aware of wot a stack pointer is, looking at so many different things to try and fix this problem my mind is locking up  and i asked an irrelevant question lool

ive looked at the stack pointer previously and although it was causing some issues when i made the stack very large to try and overlook the problem the issue with the stack pointer going into random territory or indicating an overflow was fixed however the whilst the stack is in normal territory the assembly window of hiwave is showing BRSET as it did before and just loops through BRSET for no reason that i can see.

Thanks again i do apologise for asking that question as well very embarrasing lool

[bigmac]

Hello,

The two PRM files are quite different in their structure, and to increase the size of the stack for each case will requre different measures.

For Bootloader.prm, a stack section is specifically defined, and this (unusually) lies below the APP_RAM section.

// APP_STACK_RAM = READ_WRITE 0x0101 TO 0x02C0; // RAM memory
   APP_STACK_RAM = READ_WRITE 0x0101 TO 0x02EE; // RAM memory
  
    // 802.15.4/App. general memory
   APP_RAM       = READ_WRITE 0x02C1 TO 0x0F6F; // RAM memory

I presume that you added the modified line that clearly overlaps into the APP_RAM section.  To increase the size of the APP_STACK_RAM section, the size of the APP_RAM section must be correspondingly reduced.  To double the size of the stack allocation, you might use the following -

   APP_STACK_RAM = READ_WRITE 0x0101 TO 0x04EF; // RAM memory
  
    // 802.15.4/App. general memory
   APP_RAM       = READ_WRITE 0x04F0 TO 0x0F6F; // RAM memory

The following might be an even better arrangement because APP_RAM will be assigned to variables from the bottom upward, and the stack will be used from the top downward.  This will give maximum separation between the stack section and the allocated variables (just in case actual stack usage overflows its allocated section) -

   APP_RAM       = READ_WRITE 0x0101 TO 0x0B8F; // RAM memory
  
    // 802.15.4/App. general memory
   APP_STACK_RAM = READ_WRITE 0x0B90 TO 0x0F6F; // RAM memory

Whether or not it is possible to increase the stack size to this degree will depend on the RAM requirements for global and static variables.  A check of the project.map file should show whether this is feasible.

A further improvement might be to change the DEFAULT_RAM placement sequence.  The current placement is -

DEFAULT_RAM  INTO DIRECT_ADDRESSING_MEMORY, APP_RAM, APP_RAM2;

If my understanding is correct (and it might not be) the linker will assign variables to each section, in the order given in the placement.  If this is so, there may be some advantage in reversing the order of APP_RAM and APP_RAM2, so that the APP_RAM section will be the one that is partially utilized.

Regards,

Mac

Message Edited by bigmac on 2008-03-29 03:52 PM

[JimDon]

Well, there are your usual suspects - stack too small, nested interrupts crashing the stack, wild pointer corrupting memory (and or the stack).

Quite often something like this is a stack problem - what happens is the the return address gets nailed on the stack and you return to space (a random value).