TMS320F28035: TMS320F28035 eQEP Interrupt question

Mark,

This may be nothing to do with the problem, but you seem to have a bracket mis-match on this line:

EQep1Regs.QCLR.all =  (0x0001 <<  2));      // Clear quadrature error flag -- Use write instead of r-m-w

Regards,

Richard

Hello Richard thanks for the reply

That's a typo I substituted what the mask was defined in a header file so both brackets are there . I'm looking at below and this is a bit ambiguous as to whether a zero or one clears the interrupt flag

I'm also wondering if the interrupt needs to be ack'd?


Eleven interrupt events (PCE, PHE, QDC, WTO, PCU, PCO, PCR, PCM, SEL, IEL and UTO) can be
generated. The interrupt control register (QEINT) is used to enable/disable individual interrupt event
sources. The interrupt flag register (QFLG) indicates if any interrupt event has been latched and contains
the global interrupt flag bit (INT). An interrupt pulse is generated only to the PIE if any of the interrupt
events is enabled, the flag bit is 1 and the INT flag bit is 0. The interrupt service routine will need to clear
the global interrupt flag bit and the serviced event, via the interrupt clear register (QCLR), before any other
interrupt pulses are generated. You can force an interrupt event by way of the interrupt force register
(QFRC), which is useful for test purposes.

Mark,

What you're doing is correct. You will have to acknowledge the ADC interrupt since that is enabled, but if you haven't enabled INT5 for QEP1 you shouldn't have to do anything with that.

Interrogating the PHE bit the way you have it is right, so you shouldn't be getting to the line which increments the counter unless PHE is set. Can you put a break-point on the conditional statement and monitor the PHE bit? Check it doesn't execute the bracketed lines when PHE is 0, then set PHE to 1 using the QFRC register and check it does execute those lines. It compiles and runs fine on my machine so I think this should check out.

I agree the description in the TRM is poorly worded. I will submit a lit bug on that for future improvement.

Regards,

Richard

Hello Richard

the short story is this is a very complicated architecture that has evolved over many years its a very complex AC drive I don't have JTAG access to the Picolo which communicates error to an OMAP  DSP(running loads of control theory stuff all that good MATH stuff is probally described in your book which I need to buy as a refresher ) . over SPI 

I commented out the counter( I can ftp the modified piccolo code to debug)  and the problem goes away(I'm guessing the IRQ flag isn't being cleared. I'm open to suggestions ?

In the meantime I'm taking document below home for reading

staff.ii.pw.edu.pl/.../spraa85a.pdf

wondering about  section 6 warns about writing to bit fields

Sorry, Mark, I don't have any more ideas at the moment. The code in your post looks OK, including the register accesses. I'm wondering if it's a more subtle issue involving another part of the program. I'll give it some more thought, but please let me know if you find anything.

Regards,

Richard

Mark,

There are a couple of obscure things you might like to try if you're still in difficulty.

Firtly, check whether the PIEIER and PIEIFR registers are manipulated in any ISRs. If so, there are rules for doing that which can lead to weird results if not followed. Check you have the latest version of the F2803x System Control Guide, and go through sections 6.3.1 and 6.3.2. I have put a link to the latest user's guide at the foot of this post.

Secondly, take a look at section 4.1.1 in the errata sheet for this device. This describes how certain code sequences can result in an unintended interrupt. Again, I've put a link to the document below.

Lastly, take a look at the advisory at the top of p.13 in the same errata sheet: pre-fetching beyond valid memory. What makes me think of this is that by removing one line of code the problem goes away. Look at the .map file to see where the code is located and how big it is. Again, weird things can happen if the code fetches from reserved memory space.

Regards,

Richard

http://www.ti.com/lit/ug/sprugl8c/sprugl8c.pdf

http://www.ti.com/lit/er/sprz295m/sprz295m.pdf

Hello Richard

I spoke with the author and confirmed something I need you to clarify

Can this flag QFLG.bit.PHEbe used to detect Quadrature error without enabling the IRQ?

Hello Mark,

Yes, correct. The PHE flag operates independently of any interrupt. It's status depends only on the logic states of the AIN and BIN inputs: if they change state simultaneously, PHE will be set. You could implement a polling scheme on this flag without any interrupts and it would work. You reset it with the QCLR register, as you are doing.

Regards,

Richard

Hello Richard I'm still working on getting a JTAG and I'll look into your other suggestions .

The engineer who authored this suggested as a possibility that the actual encoder HW is not compatable in other words the 38030 might be seeing actual quadrature errors I know the signals were checked for noise but I'm not sure how one could measure whether actual quadrature errors are actually happening can you comment on the possibility of this happening in your experience and what is the root cause I understand the error is caused by simulataneous changes on both A and B inputs that's all

Hello Mark,

In my understanding it's only simultaneous transitions on QA and QB inputs which can cause the PHE flag to be set. There's a nice state diagram on p.15 of the user's guide which shows these 'illegal' transitions as dashed lines. One might imagine such a thing happening if, for example, the GPIO20 and GPIO21 device pins were shorted together. Alternatively, there might be an internal encoder fault.

Can you check the physical signals at these pins to be sure there is a clear phase separation as the motor turns?

Regards,

Richard

Richard

I was able to get jtag access and verify the clear of the flag sequence works properly unfortunately I had to add the code into a background loop instead of testing whether it works correctly in the ADC IRQ not sure if that allows me to conclude the same code in ISR is working correctly. As stated earlier the counter is incremented and passed to another processor I don't think that code on other processor grabbing and filtering the count is suspect because I see the reported error on other processor go away when I remove the counter increment. I think its time to focus on the encoder  HW signals ?

Mark,

Yes, I think so too.  Many quadrature encoders deliver 5V digital outputs.  The F28035 is not 5V tolerant, so you may well have a level shifter, or clamped potential dividers, or something else in line with the QEP inputs.  

Also, please do remember to check the "fetching beyond valid memory" erratum I mentioned earlier.  I can't get it out of my head that simply removing that line fixes the problem.

One more thing, I noticed another erratum on the GPIO synchronization for QEP pins.  Could you take a look on page 21 of the F28035 silicon errata (link in previous post) for the note about using asynchronous mode at the GPIO pins?

Regards,

Richard

Hello Richard

With the scope attached there is a clear phase separation but I see no more Picolo errors now

we are usiing ALL 4 inputs A A- B B-

I'm searching for a schematic how are these signals intended to be used attached to Picolo?

Hello Mark,

The device doesn't have complementary input pins; it just expects A and B.  If your transducer has differential outputs you'll need a transceiver between it and the C2000.  

I've been searching for a TI document which would help with this but I haven't found one.  For what it's worth, attached is the QEP interface we have on the "Industrial Drive Development Kit".  Schematics and code for that kit are in the controlSUITE download.

Regards,

Richard

IDDK v2_0 QEP interface.pdf

Hello Richard

We are synchronous mode  I see the pull ups are disabled unlike the examples

Hello Richard

We have a dozen different locations all reporting this issue they choose the encoder so I'm not sure how to explain that many encoder internal faults?

We have a level shifting circuit feeding the piccolo I need to look at its output. The input to this circuit showed no simultaneous transitions

Hello Mark,

Understood. Please let me know what you find after the lever shifter. Thanks.

Regards,

Richard

Hello Richard

At this point I have to assume that noise or some other HW design issue on  the encoder interface card is causing the QEP to see quadrature errors I did NOT see an errors on scope and replacing the 28030 is not an option so the focus will be on the path leading into the picolo

I have a related question about the QEP GPIO pins

In synchronous mode with qualification we are using 3 clocks

What affect if any would changing this sample value to a lower value have on whatever is causing these errors?

Hello Mark,

In principle, input qualification ought to help if there is a noise issue. Both quadrature inputs (GPIO20 & 21) should see the same qualification, so the result will be a delay of three sample periods on both inputs. What is the sampling window width: i.e. what is Tsysclkout and the qualification period setting in the GPACTRL[QUALPRD2] field?

Regards,

Richard

Richard

The settings are as below I was mistaken its now 1 sample . What is tsysclock? we run at 60 Mhz are you referring to some internal clock ?

GpioCtrlRegs.GPAQSEL2.bit.GPIO20 = 0; // Synch to SYSCLKOUT, 1 sample
GpioCtrlRegs.GPACTRL.bit.QUALPRD2 = 9; // apply 1.5us consistency filter ((6-1)*2*(9)/60MHz)

Hi Mark,

I see GPIO20 (QEP1A) is synchronized to SYSCLKOUT, but I thought you said you were using 3 clocks for sync?  Is GPIO21 (GPIO1B) set up in the same way?  It should be.

Also, the comment about the "consistency filter" in the second line doesn't look right.  With QUALPRD = 9 you are dividing the SYSCLKOUT by 2^9 = 512, which at 60 MHz gives 25.6 us, not the 1.5 us indicated.

Can we say anything about the expected maximum frequency of the incoming quadrature pulses?

Regards,

Richard

Hello Richard

I was told the maximum frequency expected from the encoders is 200KHz.
As far as I can see the code thinks it doing input qualification on all 4 inputs but all four GpioCtrlRegs.GPAQSEL2.bit.GPIOXX = O
This means Synch to SYSCLKOUT, 1 sample ie NOT input qualification
Once I get HW back I can quickly test SETTING GpioCtrlRegs.GPAQSEL2.bit.GPIOXX = 1 or 2 for either 3 or 6 samples

I have two concerns

1) the correct values to use ie 3 or 6 samples and the period to use
2) The author seemed to be concerned that this affected all 8 pins see comment below. The other 4 pins pins are SLAVE SPI pins
// Note that GpioCtrlRegs.GPACTRL.bit.QUALPRD2 defines the sampling period
// for GPIO20-GPIO23, but it is not set here because it also defines
// the sampling period for GPIO16-GPIO19.

// PG Input A (GPIO20)
GpioCtrlRegs.GPAPUD.bit.GPIO20 = 1; // Disable pull-up
GpioCtrlRegs.GPAQSEL2.bit.GPIO20 = 0; // Synch to SYSCLKOUT, 1 sample
GpioCtrlRegs.GPAMUX2.bit.GPIO20 = 1; // Configure for EQEP1A
GpioCtrlRegs.GPADIR.bit.GPIO20 = 0; // Configure as input

// PG Input B (GPIO21)
GpioCtrlRegs.GPAPUD.bit.GPIO21 = 1; // Disable pull-up
GpioCtrlRegs.GPAQSEL2.bit.GPIO21 = 0; // Synch to SYSCLKOUT, 1 sample
GpioCtrlRegs.GPAMUX2.bit.GPIO21 = 1; // Configure for EQEP1B
GpioCtrlRegs.GPADIR.bit.GPIO21 = 0; // Configure as input

// PG Strobe (GPIO22)
GpioCtrlRegs.GPAPUD.bit.GPIO22 = 1; // Disable pull-up
GpioCtrlRegs.GPAQSEL2.bit.GPIO22 = 0; // Synch to SYSCLKOUT, 1 sample
GpioCtrlRegs.GPAMUX2.bit.GPIO22 = 1; // Configure for EQEP1S (Strobe)
GpioCtrlRegs.GPADIR.bit.GPIO22 = 0; // Configure as input

// PG Index Z (GPIO23)
GpioCtrlRegs.GPAPUD.bit.GPIO23 = 1; // Disable pull-up
GpioCtrlRegs.GPAQSEL2.bit.GPIO23 = 0; // Synch to SYSCLKOUT, 1 sample
GpioCtrlRegs.GPAMUX2.bit.GPIO23 = 1; // Configures for EQEP1I (Index)
GpioCtrlRegs.GPADIR.bit.GPIO23 = 0; // Configure as input

Mark,

Notwithstanding the qual samples, the logical setup of all four pins is fine. The GPADIR loads don't actually matter when the pins are configured as peripherals, but they're harmless.

The C comment implies QUALPRD2 is 0, but in your last post you I think said it was 9? Could you double check the GPACTRL register after the device is initialized to be sure it's what you expect? With QUALPRD = 9 and either 3 or 6 samples, the input signal would be filtered out completely at 200 kHz. In that case I suspect you might get a phase error when the input frequency crossed the upper limit, or on a change of direction.

I think the setup you want is: GPACTRL.bit.QUAPRD2 = 0, and GPAQSEL2.bit.GPIO2x = 0 for all four QEP pins.

Regards,

Richard

Hello Richard
Current settings are QUALPRD = 9 and GPAQSEL2.bit.GPIO2x = 0 with as many as 360 qudrature errors in 3 seconds

My goal is
1)verify the current settinngs are correct (will these settings cause errors that dont exist?)
2)If I'm still seeing errors with proper settings filter out any noise using qualification(is this possible with my constraints?)

Hello Mark,

These settings should not be causing the errors you are seeing.  Is there any chance you can send me the complete configuration code for the QEP module?  I can configure a device here and attempt to replicate the issue.  Also, please do check the register values in the CCS expressions window while the motor is running to ensure nothing has been changed unexpectedly.

Regards,

Richard

Hello Richard

I'll have to check on that. I would like to get some clarification several things

1)on input qualification
With GPAQSEL2.bit.GPIO2x = 0 there is no input qualification correct?
If that's your intent why would you set QUALPRD = 9 ?
or is sampling still happening for 9 SYSCLOCK clock ?

2)Your previous reply you say

Notwithstanding the qual samples, the logical setup of all four pins is fine. The GPADIR loads don't actually matter when the pins are configured as peripherals, but they're harmless.

I was asking about the QUALPRD setting not the GPADIR
Does your reply still apply ie if 4 of the GPIO pins are SPI peripheral?
Since the QUALPRD affect all 8 pins I might have a situation where 4 sets of pins needed a certain QUALPRD and the SPI requires something else to work properly. I see examples were the SPI setup is setting QUALPRD please elaborate

Mark,

1) If GPAQSEL2.bit.GPIO2x = 0, the input will be synchronized to a single SYSCLK cycle. QUALPRD does not affect this configuration.

2) All qualification and synchronization affects the GPIOs even when configured as peripherals. Care must be taken that if signals are using 3 or 6 sample qualification, the other IOs in the group use the same QUALPRD. so you are correct. If only 2 signals need Qualification, you can set the other IOs to be either synchronous or asynchronous, so they are not affected by the qualification period.

Have you been able to observe the QEPA and QEPB signals after the transceiver?
Can you share the full EQEP configuration and GPIO code as well? could help us recreate a setup here in the lab.
Have you been able to determine a common condition where the PHE error occurs? Temperature, Rotational frequency? change of direction?

-Mark

Hello Mark

<<Have you been able to observe the QEPA and QEPB signals after the transceiver?
Yes I don't see an phase errors.


<< Can you share the full EQEP configuration and GPIO code as well? could help us recreate a setup here in the lab.
I could provide the register setting for those and order of initialization and use case but not original source code.
I need a couple days as I focus on your question below I'm trying to reproduce on another set of HW I DONT HAVE ACCESS TO THE original at the moment

<<Have you been able to determine a common condition where the PHE error occurs? Temperature, Rotational frequency? change of direction?

When it fails and it doesn't always fail it fails quickly 3 seconds Ill try and characterize it better in the next days

I have a question about noise rejection assuming it exists. It appears to me that input qualification can not filter out 100 % of noise
Do you agree that if noise is causing this issue input qualification might not help especially with 4 of the 8 pins being used as SPI pins and the bandwidth (200khz max) . From timing diagram it looks like noise that happened during the sampling period would be a problem?

Mark,

The GPIO and EQEP configuration code would be all I need. Any additional use-case information that you think might be useful would be great to have as well. Please feel free to share these with me offline if they are sensitive.

I am not quite sure that I understand your question. If the EQEP is set up for just SYSCLK synchronization, the QUALPRD set for the SPI should not affect the EQEP.

-Mark

Hi Mark

I verified all register settings with JTAG while the original code is probally derived from your examples I can provide you pseudo code I created of the flow of the requested areas. It wont be a big deal to get it converted

<<Please feel free to share these with me offline if they are sensitive.

Its ready so provide me the method to send this

Mark,

I have sent you a friend request which will allow us to exchange information in a private message. Please accept the request so we can continue our debug.

Please share the EXACT EQEP configuration code. copy/paste is best.

-Mark

before we proceed do you think that incorrect setting in these register could cause these Phase errors ?
Do you have a phone number I could call you?

I am not certain of anything at this point. Without additional information such as your exact QEP and GPIO setups or even any scope captures it is very difficult to know what state the QEP is in. If there is an invalid configuration or even a corner-case type of setup, problems may arise. I can use this information to try to replicate the setup and even confirm with our design that the configuration is valid. 

Speaking of the scope capture, it would be great if you trigger a scope on a GPIO that is toggled when the Phase Error Occurs ensure the QEPA, QEPB and QEP Index signals are on the scope as well. This will prove that the signals going into the QEP signals are not in fact causing the Phase error, meaning something inside the chip is causing the error.

Have you had any success testing other conditions to see if there is a common cause of the failure?

Is this custom hardware? Are you using a TI kit?

Regards.

Hello Mark

I'm having trouble getting the equipment I need to replicate this but hope to get that soon

I would like to comment on your suggestions below

<<Speaking of the scope capture, it would be great if you trigger a scope on a GPIO that is toggled when the Phase Error Occurs ensure the QEPA, QEPB and QEP <<Index signals are on the scope as well. This will prove that the signals going into the QEP signals are not in fact causing the Phase error, meaning something <<inside the chip is causing the error.

a) If indeed I capture on a scope the failure and it shows no phase errors I can appreciate how TI would be interested in replicating and fixing any such issue however replacing the processor is not an option for us and may be beyond the scope of my job but I can certainly check into helping you

b) your trigger suggestion won't work because the phase error (quadrature) is detected by polling and turning on interrupts and adding extra code will change the behavior of the Picolo firmware that  expects certain high priority interruptrs. Its worth a try but again this just takes me back to A above

My thinking is this has to be fixed in piccolo  firmware which there does not seem to be a solution (beyond attempting some qualification filtering on incoming pins )

I will update you when I get the hardware to replicate the issue

Mark

Mark,

Thanks for the update. Please let me know when you are able to replicate the issue.

Please be sure to track any useful conditions that might be related to the error presenting itself. Temperature, motor speed, motor direction, etc.

Regarding b) Only one additional line of code is needed to change the state of a monitor pin. This is as unobtrusive to the code as I can think of. There is no need to enable any interrupts or add new branches. From your original posting, you can just add the toggle code after (or in place of) the error count increment. This is only for debug purpose to trigger the scope on the error detect to see if the QEP is in fact generating this error without an actual Phase error between QEPA and QEPB signals.

// Update position feedback quadrature error count

if ( EQep1Regs.QFLG.bit.PHE )

{

 sPosFdbk.QuadratureError++;

 // GpioDataRegs.GPxTOGGLE.all  = (0x0001 << x); // toggle monitor pin

 EQep1Regs.QCLR.all =  (0x0001 <<  2));      // Clear quadrature error flag -- Use write instead of r-m-w

}

If we can prove that you are seeing the error bit get set without seeing a phase error in the actual QEP signals, we can work to figure out how I can replicate here. We can cross that bridge if we get to that point. If it means sharing just QEP configuration code, or sharing one of your failing boards and having some debug calls, we can make that happen. 

Thanks,
Mark

<<<If we can prove that you are seeing the error bit get set without seeing a phase error in the actual QEP signals, we can work to figure out how I can replicate here

Our HW team has the failing HW since Monday they will characterize the failure and gather scope captures

just to reiterate I wont be able to supply any SW to replicate the issue without an NDA and permission from appropriate people we can cross that bridge when we come to it