High CAN traffic causes A/D reading to increase

[newguy]

I think I'm facing a memory corruption issue. I have two prototype boards and they both have this issue, so I've ruled out the possibility of it being a hardware fault that is present on only one board. Running a dsPIC33FJ256GP710A, PCD compiler version 4.141.

I'm using DMA to scan and convert 7 A/D channels. Once all 7 channels have been converted, the DMA interrupt fires and my code then extracts the samples where they're processed out of an interrupt.

I'm also using DMA to handle CAN reception and transmission (only one CAN transceiver on this chip is being used).

I'm also using DMA to handle UART (UART1) transmits.

This project is based on several existing projects that all work and all incorporate some or all of the DMA A/D, DMA CAN and DMA UART transmit code.

The issue that I'm seeing with this project is that high CAN traffic (a CAN packet causes a serial transmission on the UART and a received UART packet causes a CAN packet to be created; if I disconnect the hardware that is attached to the CAN lines, effectively disabling CAN traffic, I don't see the A/D creep on channel 0) will cause my A/D channel 0 (and only channel 0) to monotonically increase over time. I should clarify: the actual A/D reading DOES NOT change, but the output of the filtering that I do on the samples creeps up. The amount of creep is directly correlated to the amount of traffic. The lines that carry the CAN traffic and the serial traffic are placed well away from the A/D lines. The A/D filtering circuitry is well separated from the CAN and serial circuitry so I don't believe it to be a crosstalk issue. Indeed, the fact that the raw sample of A/D channel 0 does not change whether there is high CAN/UART traffic is proof that this isn't an analog issue.

I don't have any overlap in the DMA buffers used by the various processes. Increasing the stack had no effect so it can't be a stack issue. The A/D DMA process is the highest interrupt level (6), with the CAN and UART transmit both being level 5. Since the A/D process is higher priority, I can't imagine how high CAN and/or serial traffic could corrupt it.

As I mentioned, I have other projects that have no A/D corruption issues that employ virtually the same code structure.

Any ideas?

[temtronic]

Power supply not strong enough ? If the Vref of the ADC is Vdd having a 'lot of traffic' could drop the Vdd, thus affecting the ADC.
yeah, I know a long shot but you did ask for ideas !

Jay

[PCM programmer]

So it's getting corrupted in your ADC filter code. What happens if you
make the local variables in the filter routine into global variables ?
Does the creep go away ?

Also, what if you do a very simple filter, instead of some complex filter ?

Also, could the problem possibly be related to non-atomic code being
generated for the adc_result variable ? This may not be an issue on
the dsPIC33 with the PCD compiler (I don't have that compiler), but
it should be checked.

Also do a Google search for this:

[Ttelmah]

I'd be very suspicious of erratum 14.
Obviously the probability of this rises the more CAN traffic that is being generated. Effectively you need to disable DMA at any time the CAN SFR is updated to avoid this one.
It'd result in corrupted DMA registers, which could easily give unexpected values.

It's also not clear what sample rate you are using on the ADC?. Single channel or twin channel?. Erratum 13 might apply if you are using dual channel mode.

Erratum 6 also has 'nasty' spread all over it. Wouldn't affect the ADC input, but would mean corrupted values when writing to any memory 'in use' by the DMA.

As a comment, the trap interrupts are all higher priority than the conventional interrupts. Is it possible you are getting CAN trap interrupts?.

As a comment, try lowering the priority of the ADC.

A slight delay in handling the ADC shouldn't matter, and this way round updates to registers in CAN transactions would not affect the ADC.