WIN-AVR trouble

ut

Do you have the watchdog enabled without appeasing it?

What happens if you comment out that line?

This doesn't make sense to me but the problem seems to deal with callin functions between these two c files. The code for lowering the ss is i "spi.c" and I'm calling the function in "flash.c" It would seem tha anything I call form spi.c will stall and then start at the beginning o main. But like I've said, I have a 3rd c file that has no problem calling functions from spi.c.

When I look at the assembler the part where it fails is:

It seems to have trouble with the subroutine return.

calling

in

of

Well I'm using an Atmega169P and I'm compiling it as an atmega169. P i only supported by the assembler but I've done this before withou consequence. This wouldn't be the first "ret" instruction anyways.

Have you got the correct -mmcpu= flag in your makefile, and are you passing it on to the linker properly? If you've got the mcpu flag wrong, it's quite possible that the program runs okay to start with, but your stack is in the wrong place - thus the first "ret" instruction kills your program.

calling

in

of

Well I'm using an Atmega169P and I'm compiling it as an atmega169. P i only supported by the assembler but I've done this before withou consequence. This wouldn't be the first "ret" instruction anyways.

Are you sure that there is not a short from the affected SS line to the supply line so that clearing the bit kills the power?

Another pretty similar possibility is a short to the reset- line.

"Joel" skrev i meddelandet news:ZICdncEzD61n8UPanZ2dnUVZ snipped-for-privacy@giganews.com...

PORT_SPI is PORTB, I put the commented part there so you could see what m defines were respectively. I have stepped though it with a JTAG ICE. That's how I know the assembly line where it quits on me.

I'm sure there is no short. I've checked it and rechecked it over an over but I can be dead certain because if I include and replac the function call with code:

PORTB &= ~(1

"Joel" skrev i meddelandet news:fOCdnb-mJIkuOkPanZ2dnUVZ snipped-for-privacy@giganews.com...

Are you sure your stack is initialized properly. No overflow?

Why not use:

#define cbit(port, pin) port &= (1

Perhaps one of the functions in spi.c (or an interrupt) corrupts your return stack ?

... snip ...

Probably because you have fouled the stack.

Joel ha scritto:

so, is not PB4 falling that trigger external interrupt PCINT12 without proper handler. stack overflow/underflow ?

That sounds like the problem to me.

Using #defines like that is *so* last century :-) It is better practice to use "static inline" functions than #define's unless you actually

what my

and

replace

can't

I could do without the subroutine just to get it to work. That woul include an extra include of which I could do but I just want t know why the way I have it doesn't work. I don't think I'm dealing wit stack overflow/underflow simply because I've got so much memory stil available. Here is a picture of my memory window while stepping throug right at the part where it stops working from AVR Studio:

The numbers in red toward the bottom are the "ret" address from th assembler. But it doesn't go back there, instead it times out and start over.

After many more experiments I've determined that spiLowerSS1() is just on of many functions from spi.c that behave this way when called. However, have a function in spi.c which I can call without problems. That functio is called spiDataFrame and it calls these "trouble" functions without an problems at all. In the disassembler these are Jumps instead of jus subroutines. I have no trouble calling and returning from spiDataFrame a a subroutine though.

Thanks for all the ideas so far.