Halting the mainISR in F28027 during motor spinning

It is always possible that an interrupt becomes disabled because the PIE mechanism is not being used properly.  It's very unlikely to be a hardware issue though.

Take a close look at the IER and PIEIER registers when the issue occurs to be sure they are correct.  

Also, be sure you are following the rules for modifying the registers, if any other active interrupts are in the same PIE group as your main ISR.  Check section 6.3 in the system guide:

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

Regards,

Richard

In your code, after the problem occurs did you check the interrupt enable and flag registers as above?  Is everything correct?

If you can say it always happens when the torque ripple rises, please check two more things: 

 - are you getting a PWM trip?  You can check this at U2 on the board, and in bits 1 & 2 of the TZFLG registers.

 - is the device being reset?  Please monitor the device power rails to ensure the voltage remains within spec at all times.  Also monitor the /XRS pin to ensure it remains high.

Regards,

Richard 

- first of all, i must say that, i design a new board base on a TI_HVKit with F28027, and i didn't use U2 in my board to trip the ePWM block, so it couldn't be the reason. i used another mechanism for triping and connect it to GPIO12(TZ1) and for a test i disable this mechanism but the problem is still there.
- second, i used two toggling LED for recognizing the system state. one in the mainISR and another in main routine(for(;;)). after the problem occure, the mainISR LED didn't toggle anymore but the main routine LED keep toggling. if the MCU is being reset, both LED must work together but just the main routine LED works. in addition to this, i have a relay in beginning of my code and if the MCU reset, it must make a sound but it didn't, so the MCU didn't reset.
-third, for trip zones, i didn't change them and as i know the TI original program disable the trips in HAL_setupPwms() function.

- as i understand from the original TI code, the mainISR is the ADC end of Conversion and trigger by ePWM overflow(15khz pwm so mainISR repeat every 66.6uS). until now i was thinking that maybe the ADC halt in sampling but now i think maybe the ePWM halt in the middle of counting. is it possible that the ePWM block trip by the internal or software TZ?

is there any other test that i can do?

sorry but i couldn't test the power rails. i will do it so soon and say to you.

i ran a original code in HV-Kit(with F28069 Control Card) and get a near answer to answers in my designed HV-Kit.

during this test i have done many tests and find somethings.

1- when this problem occur, the mainISR function(ADC1 EOC INT ISR) never execute again. i search for a reason of this and found that
before occurrence of problem, the ETFLG register(Event-Trigger Flag Register) have a value of 0x04. it means that the SocA event create by reaching the pwm counter((TBCTR)) to zero, and make a soc on adc block.
but after occurrence of the problem, the ETFLG register have a value of 0x00. it means that the SocA event doesn't create anymore.
i went deeper and found that the pwm counter register(TBCTR) work fine and count correctly. but the SocA doesn't work fine.

2- in the beginning of hardware initialization(just after the HAL_setParams() function calling) the value of ETSEL register(Event-Trigger Selection Register) is 0x900. it means that the EPWMxSOCA enabled and EPWMxSOCA pulse will generate when TBCTR = 0x0000. this value is constant before calling the HAL_enableGlobalInts(halHandle). after that the value of ETSEL is become 0xE00 and remain in this value. this value is not related to our goal.

so why SocA event doesn't create anymore?
and is it possible that the problem is occur because of ETSEL wrong value?

If ETSEL is changed from 0x900 to oxE000, the SOCAEN field is changing from 1 to 0.  Therefore SOCA is disabled and you will not get any further SOCs.  Probably this is the reason your main ISR stops.  Now, the question is 'why'? 

You seem to be saying the same code running on your board, and on the TI HV-kit, behaves the same.  Go ahead and check the power rails carefully, but I'd say we are looking for a software reason why that register is being changed.  I don't know your software structure, and am not too familiar with MotorWare, but you may be able to poll that register at various points in your code to get an idea of when & what is modifying it.

Are you using TI-RTOS?

Regards,

Richard

hi Richard,

thank you for your help.

i found the problem.

it's look like that the MCU can't compute the value in the right time when the torque ripples increase. maybe when the values become bigger this problem happens.

i solve this problem with simple approach. one of my colleague offer it.

i changed the value of USER_NUM_PWM_TICKS_PER_ISR_TICK from 1 to 3.

it means that ADC EOC ISR execute with 5khz rate instead of 15khz.

thank you following up.

Hi msadegh,

I'd hate to revive an old thread, but hopefully you're still around to respond. Could you elaborate on what calculation you thought was causing this problem? It seems strange to me that it would be possible to reset the ETSEL register by giving the MCU certain computations. I think I'm experiencing the same problem with the Main ISR stopping triggering, but I can't catch the actual event (It'll happen after hundreds of hours of testing). 

Or if anyone from TI could offer some insight into this situation, that would be great.

Thank you,

Nathan

Nathan,

I have to agree it is hard to see why the ETSEL register might be getting corrupted.  Your issue will be hard to debug if it happens so rarely.  A couple of questions occur which may help:

Do you have any indication of the status after the fault has occurred?  Are you seeing a change in ETSEL, PIEIER or other registers?

Can you reproduce the problem in the lab, with or without a motor?

What does the main ISR look like - is context save/restore protected?  

Could this be a stack overflow?  You can check for that by filling the stack with a known data and then checking to see home much of that remains after the problem.  There is also an application note explaining how to implement stack overflow detection on C28x using the internal breakpoint registers (spra820).

Lastly, are you manipulating any of the PIEIER registers while interrupts are active?  If so, there is a procedure for doing that which is documented in the User's Guide.

These are just some questions to stimulate thought.

Regards,

Richard

Thanks Richard for the reply. You gave me a lot of good things to keep in mind.

I wanted to respond because I think I've isolated the problem and wanted to share. Currently we do the following:

1. Disable global interrupts, Copy all ADC, PIE registers to RAM

2. Run several routines from the IEC safety library 

3. Write back to the registers from RAM, enable interrupts

Steps 1 and 3 are done because of concern that the IEC routines were causing issues, so we wanted to preserve the state of our registers. This whole process is only done once every two minutes while the motor is spinning, hence this issue being so intermittent. 

I see many opportunities here for a problem. Writing to the PIEIER registers, PIEACK, etc. I disagree that steps 1 and 3 are necessary. Removing them has fixed the problem.

Thanks again for the help!

Nathan