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:
+000004CD: 982C CBI 0x05,4 Clear bit in I/ register
+000004CE: 9508 RET Subroutine return
It seems to have trouble with the subroutine return.
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.
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.
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:
Using #defines like that is *so* last century :-) It is better practice to use "static inline" functions than #define's unless you actually
*need* to use the #define. The compiler will inline the functions and generate a single instruction (as long as you use -Os, or other optimisation flags).
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:
formatting link
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.