Keil Logo

C166: Stack does not update memory!

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
Mikael Briday
Posted
9-Jan-2007 10:54 GMT
Toolset
C166
New! C166: Stack does not update memory!

Hi,
I have a Stack problem in an interrupt handler.

When I use a PUSH or CALL instruction, SP is correctly updated, but the memory at the address pointed by SP remains 0!!
DPP3 = 3

I checked under monitor control, but the program in Flash still crashes.

STK_SIZE fields in SYSCON to 7 (in startup code): No wrapping: entire internal RAM used as stack.

The behavior with the simulator is OK.

The system stack is F800 - F880, and SP is in the correct range, problem detected with SP=F860.

I've tried the code with 2 C167CS cards, this should not be a hardware pb.

Thanks for any help,

Read-Only
Author
Chris Wunderlich
Posted
9-Jan-2007 13:57 GMT
Toolset
C166
New! RE: C166: Stack does not update memory!

Sorry, but I don't see the problem. If I understand you correctly, this only occurs in the interrupt handler when you make a push? Is there any way to show the disassembly or a small example so someone can have a better look to what could be happening?

Read-Only
Author
Mikael Briday
Posted
11-Jan-2007 06:48 GMT
Toolset
C166
New! RE: C166: Stack does not update memory!

The problem is that the memory is not updated after a PUSH.
For instance, if
* SP=0xF860
* the instruction PUSH R13 is executed (in the interrupt handler, under the control of the monitor, step by step), with R13=0xF432

Then SP is updated to 0xF85E (ok), but the memory at this address remains 0!!

I wonder if the memory is correctly refreshed by the monitor and my program crash with other reasons :-/ ?

Thanks for your help,
M. briday

Read-Only
Author
Mikael Briday
Posted
11-Jan-2007 21:37 GMT
Toolset
C166
New! RESOLVED: C166: Stack does not update memory!

I found the error.
The monitor was compiled with STKSZ (of SYSCON) set to 0, and it must be 7 (I managed stacks manually for different reasons)
I changed this field to 7 in the start1167.a66 file, but this was not sufficent.
That's why the monitor sent hazardous data to the IDE.

Next Thread | Thread List | Previous Thread Start a Thread | Settings

  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.