Hi, I'm back with more questions :)
I have a 4-element array of 4-byte bit field structures filling up my bit addressable memory. Those structures are manipulated a lot in my code. I have found that assigning a pointer to an array element and then working with it generates much less code than working with the element directly. In one piece of my code, I want to do a logical operation with a lot of 2-bit structure fields. A line that does that looks like this:
pointerToStruct->2bitField ^= pointerToStruct->2bitField << 1;
This is compiled into a lot of instructions, but the beginning looks like this:
MOV R0, 0x01 PUSH MOV A, @R0 MOV R4, A
My program breaks at the last instruction with error 65: access violation at I:0xE7: no 'read' permission. When I look at my registers, R0 really contains 0xE7. The first instruction should have put 0x01 in R0. PUSH should not have affected it as far as I know. If I check &pointerToStruct in the watch windows, the address is really D:0x01, so this should be ok.
Any ideas about how 0xE7 ended up in my 0xE7? Is it possible that my stack overflows? If it tried to go beyond 0x7F, would it wrap around and start writing into register banks or what?
The function I'm calling from both main and timer interrupt is not a problem. That one works correctly. It's for the initial mode of my 8051 and it will be called forever until the program is set into some other mode, which is when my problems start. I removed the function call in main, but it only changes the place where my other function tries to access something that is out of bounds.
My chain of calls is timer_isr (using 1) --> oneOfFourFunctionsInATable (using2) -> oneOfTwoFunctions (using 3)
oneOfTwoFunctions is the one that is receiving bad parameters through registers. Is this kind of set up a no-no as well?
Is this kind of set up a no-no as well?
That's actually even worse. It's the same no-no, except you cause it fully explicitly instead of letting the compiler break this on its own.
are you aware that functions can not call functions with a different 'using' if you are, the compiler should give a warning NEVER ignore warnings
Erik
Thanks for help. I wasn't aware of it. None of the sources mention it. Also, I got no warnings from the compiler at all. I'll remove the 'usings' and hope I don't overflow the stack.