Global variables access issues

[Bryan]

I increment a global count variable in an ISR, and then print the result after the calculations are performed using the UART and this works correctly - I get what was expected. Unfortunately, when I try to access this variable in a function which is called in my main loop later on, it is not accessed period when I try to call it in a for loop inside this function. Do I need to disable the ISR where the global variable is incremented? Are there access issues with global variables that I am unaware of? Any help would be greatly appreciated! By the way I am using a PIC18F2580.

[asmallri]

It depends. If the variable is a byte or a bit no, anything else yes.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Bryan]

Could you be more specific? The variable I am incrementing is an int, but I am also having trouble accessing an array that is a global which is filled in in the ISR. I use my incrementing variable to fill in the array elements sequentially like the code below:

[asmallri]

There are 1 to 3 possible problems. It depends on your compiler version and you PIC rev.

1. Some versions of CCS save the interrupt context for the fast handler, some do not. There are pros and cons either way. For the sort of low latency critical high priority interrupts I usually use, the compiler is very inefficient and would prevent my code form operating correctly. For example I have two full duplex software UARTS running at 115Kbps which would not be possible with the compiler saving the context. Depending on the compiler version, the fast directive no only sets the interrupt as a high priority interrupt but also results in the fast return option being used where the PIC restores the BSR, WREG and STATUS registers from the shadow registers.

2. Some 18F series PIC (most) are broken with their fast interrupt handling. This is because the shadow registers for WREG, STATUS and BSR, may hold the incorrect entry if a movff instruction operating on any of the non shadowed versions of these registers was interrupted mid step. The result is the shadow versions are not correct and therefore when returning form interrupt the processor status was corrupted. So if you happen to have one of these PICs and the compiler does not have the context for you then your application can crash and burn. The work around is to save these registers yourself (using movff instructions) and exit the handler via your own _asm RETFIE 0 _endasm instruction.

3. In your example you use an array data[] inside the handler. Now the compiler might be using the FSR0 registers to do this but if the compiler is not saving the context, then these registers are being corrupted. Therefore, depending on point 1, you may also need to save the FSR registers. It is easy to tell just dump the listing. The compiler can (and often does) generate rather convoluted (inefficient and using more registers) for dealing with arrays. So, if your compiler version does not save context, here is a cleanish work around: inside the FAST interrupt handler

[Bryan]

Thanks for the help! My bitpos is a simple int and the array data is an array of longs. The weird part with this is that if I read either bitpos or the various data locations in the array in main, everything seems to be consistent and ok. If I try to access either of these from a function that is defined outside of main and called within main, I run into problems.

Another strange problem I have is that when I try to disable my ccp interrupt after I have collected all of the data from the incoming signal (I am doing signal reading) I no longer get anything. This is strange because I know my disabling is happening after the data has come in and I have verified this. Any ideas why this might be the case?

[asmallri]

[Bryan]

I disable the interrupt AFTER I collect the data.

The only reason I thought this would be needed was because when I print out my array, I am only expecting 49 pieces of data, but the array was still getting data even in the positions that weren't supposed to be filled (Since it is sized as 88 wide I checked all 88 and 50-88 are filled with junk data seemingly random numbers). Now that you have mentioned the shadow register corruption it would make sense that this is why the array is getting all the junk data in it.

What do you mean by:

[asmallri]

[Bryan]

Could you please describe in more detail what your ASM code does from a couple posts back as I am not familiar with some of the instructions you are using. Namely these lines:

[asmallri]

[treitmey]

a poet as well !