CCS/DRV8312-69M-KIT: Incremental encoder freezes control algorithm

Could you please have a more detailed description of this question? What encoder are you using? What power supply and consumption is the encoder? Did you monitor the power supply (5V & 3.3V) of the board? What pwm frequency are you using?

Yanming,

Here's some more detail:

- I have the DRV3812-69M-KIT
- Using CCS Version: 8.1.0.00011
- I'm running latest version of Instaspin 'motorware' from website.
- I'm trying to run a relatively low inductance 'disc' motor, link:
" www.portescap.com/.../32bf_nuvodisc_specifications.pdf "

I've added 180 uH inductors to make the R/L ratio more satisfying for tuning, etc.
I've also reduced the P/S to 14 VDC, (want a bit more pulse width).

I've been able to 'tune' and get consistent values for Rs (1/2 datasheet value, it's a wye motor), Lsd, Lsq, Inertia and Friction that make sense.

I can successfully run the lab 02a/b/c exercises. [I get numbers that make sense.]

Ultimately, I need to run at low speed using an encoder: I'm trying to run lab 12a/b.

Whenever I try to use the encoder (CUI AMT313Q-V, link: " www.cui.com/.../amt31.pdf ")

After a few seconds of running, I have 'ESTOP0' occuring at address 0x3ff4fa. The code looks like what I'd expect to find in PIE_illegalIsr(), but it's the wrong location.

The system shuts down and seems to clear the PIE, etc.

(I'm not new to Motion Control and DSPs, I was a drives designer for Allen-Bradley and Rockwell for several years.)

The Encoder cable is shielded, twisted pair, I'm using the A+ and B+ outputs from the differential encoder outputs, the waveforms are clean and swing the full 5 volts. However the problem occurs even without the encoder connected.

Encoder is connected through ferrite, wrapped 3 times at the DRV board. 0.1 uF capacitor installed in addition to the ones on the DRV board.

- Problem only occurs when the cable for the encoder is plugged in, with ANY of the lab exercises, even those that don't use the encoder.
- Doesn't need to have the encoder connected, just the QEPA or QEPB pins. (I removed pins from the connector to see what effect it had.)

When problem occurs, the SP goes to 0x000C

I've looked at stack overrun, ('fill'ed the stack with 0xAAAA) it only uses from 0x400 to 0x508: so probably not a stack overrun.

Looking for an unexpected interrupt, which led me to looking for/at PIE_illegalIsr().

The code it locks up at looks like (disassembled) PIE_illegalIsr(), but it's at the wrong address(?)

I could use some help on this and it appears that other folks have also seen this, (I've been trolling the Internet and your support site).

I'd love to have a phone call about this, is that possible?

Is there a local TI DSP support contact? I work with Avnet and Arrow extensively.

Thanks,

John Miramonti

FYI: Cabling is shielded twisted pair and only about 18 inches, dressed away form the board. Also occurs if motor is disconnected.

More information: It appears that the Encoder somehow causes the issue. apparently starting rotation of the encoder somehow rocks the 5 VDC on board supply. (I was rotating it by hand.) I've moved to a separate Power Supply for the Encoder (data sheet claims it has a typical draw of only 16 mA, and I measured it and it looks to be more like 20-30 mA). I'm thinking it throws some kind of current transient at startup that is somehow bouncing the DSP causing us to ESTOP? More investigation to follow. But at tleast now I can run the encoder in lab 12b.

It seems like the current of LDO is not enough for both controller and encoder, so the MCU went to brown-out and jump to an illegal interrupt.