variables being overwritten - 2.236 - PIC18F258 - can bus

mbge5amw · Joined: 13 Dec 2004 Posts: 15 Location: Yorkshire, UK

I have tried to recreate this in a smaller project but have been unable, I have therefore picked out what I think may be the relevant parts of this project to see if anyone can see what is going wrong.

99% of the time it is running fine, however I appear to be getting memory corruption.
I have found talk on the message board of problems with certain compilers overwriting data with the can bus routines but I am using 2.236 which sounds to be the most stable.

I have a motor control project which basically goes like this.
Incoming data on CAN bus is buffered in interrupt routine.
Main loop then decodes this data to work out required motor speed, using motor_convert_100_12 amongst other routines.
Timer generates interrupts at varying rate to cause next step to be written to stepper motor.
Also when a sensor is triggered the current position is stored in memory ready for the main loop to check that the motor is where it is expected to be.

The memory that gets corrupted is the first 2 elements of the array motor_fast_step_size_lookup[] i.e. addresses 02A and 02B
The value of 02B after corruption just happens to be the variable passed to motor_convert_100_12() and this routine uses addresses 22A and 22B for data manipulation.

I have confirmed that I am not writing values to the array motor_fast_step_size_lookup[] through errant code - this is normally written once on power up and then referred to from then on.

I imagine that for some reason the bank address for data writing is getting corrupted and changed from 2 to 0, but I cannot see why.
Am I right in thinking that the compiler should handle all this, I am a bit stuck now to see what I can do.

If you wish to see any other aspects of the files I can provide the relevant info.

Thanks in advance for your help.

Andy

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

You have an array that's getting stepped on. Your believe that it's
caused by some sort of addressing problem.

Here's something to try. Rename the original array by appending
"_old" onto the end of it. Leave it in its present location as a place
holder. Then create a new version of the array (with the original
name) up in an out-of-the-way RAM location, say, up at 0x500.
Use the #locate directive to do this. Example:

mbge5amw · Joined: 13 Dec 2004 Posts: 15 Location: Yorkshire, UK

I have made that modification exactly as described above and the fault remains affecting the same location,
ie motor_fast_step_size_lookup_old[] (at 0x002A)is getting overwritten
but motor_fast_step_size_lookup[] (at 0x0500) remains intact so far as I can tell.

This seems to be a good fix for now, as my genuine data is uncorrupted, but I remain worried that the cause of this data corruption may also affect another location that I can't spot so easily and thus lead to niggling bugs remaining in the code.

As a crude workaround, is there perhaps a switch that will force the compiler to always specify the memory bank before accessing memory, or to always use 16 bit addressing. I realise this would probably slow the code down but this may be a necessary sacrifice in order to ensure reliability.

TIA

Andy

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I agree that the cause should be found. The real way to find it would be
to use an ICE and trigger it when a memory write occurs to 0x2A.
Without an ICE it probably has to be done by inspecting the .LST file,
so a smaller program would make it easier.

mbge5amw · Joined: 13 Dec 2004 Posts: 15 Location: Yorkshire, UK

I could take a look at shrinking the code but this precise problem has only come to light in the latest stages of code development, I am concerned that shrinking the code would simply make it go away as I would take away the exact set of triggers.

A few ideas I have:
1. Is the memory bank setting, as set by MOVLB, automatically stored in the stack during interrupts? Perhaps a stack overflow due to numerous interrupts and deep subroutines? I'll have a search on the forum to find some more info on this and see what looks relevant to my project.
EDIT - not this as I already had the STVREN fuse to protect from this

2. ICE: I have an ICD-U40 but using the command line PCM compiler. Do I need to upgrade to PCWH or do I also need to upgrade the hardware too - as far as I recall the ICD allows you to put break points in code but not conditional breaks.

3. Try very slimline code but keeping all the existing interrupt routines.

4. Check for any hardware errors as described in http://www.ccsinfo.com/forum/viewtopic.php?t=27543&highlight=silicon+bug

mbge5amw · Joined: 13 Dec 2004 Posts: 15 Location: Yorkshire, UK

OK, I'm not sure now if the latest change I made (while systematically reducing the code size) has rectified the fault or simply masked the symptoms but it certainly looks to be behaving itself at the moment.

FYI what I found was a problem with my CAN bus comms.

I have written a routine that takes the latest CAN bus command and puts it into a FIFO buffer.
This routine first checks to see if there is space in the FIFO buffer, if there isn't space then it is left in the hardware buffer until space is made available - the idea being that the hardware will inform the transmitting device that it has no more room and so it should try later.

This routine is called from each of the two CAN bus interrupts in order to get the fastest response possible most of the time.
It is also called from the main loop in order to process any commands that were left in the hardware buffer during the ISR due to a full FIFO buffer.

I did not want to have any of the variables used in this routine stomping on each other due to reentrancy so defined the code as inline so that 3 separate instances were made of it.
Unfortunately I overlooked the fact that the final destination - i.e. the FIFO buffer was a global variable and this and its write pointer was referred to by all three instances of the routine.

I have now removed the inline definition and the compiler is helpfully disabling interrupts while this is called in order to prevent reentrancy (with the added bonus of saving me a significant amount of code space)

Ideally I would like to handle this myself with a flag that prevents recurrent execution of the code within the routine, thus I can still have the timer interrupts occuring in order to write steps to the stepper motor but that is a separate issue which I ought to be able to work out for myself.

Thanks for listening to my ramblings.

Andy