TMS320F28054M: TMS320F28054M

As you mentioned above. The issue could be from the noise that could be different in debug and run mode since the emulator is connected to cause the power supply or ground is different in these two modes.

What emulator is using for the board?

Dear Yaming, Thanks for the reply.

I think, it is not the noise issue, I have used TRIP pin (GPIO8) and CRO with following code in ISR just before PWM is updated to confirm the value gPwmData.Tabc.value[0] is within 0.5 to 0.6. So the PWM reverses as seen in graph, even when TRIP pin shows pulse indicating, gPwmData.Tabc.Value[] is correct. 

------------------------------------------------------------------------------------------------------------------------------------------------------------

if(gPwmData.Tabc.value[0] > _IQ(0.5) && gPwmData.Tabc.value[0] < _IQ(0.6))
{
GPIO_setLow(halHandle->gpioHandle,TRIP);
}
HAL_writePwmData(halHandle,&gPwmData);
{
SVGENCURRENT_IgnoreShunt_e ignoreShuntNextCycle = SVGENCURRENT_getIgnoreShunt(svgencurrentHandle);
SVGENCURRENT_VmidShunt_e midVolShunt = SVGENCURRENT_getVmid(svgencurrentHandle);

// Set trigger point in the middle of the low side pulse
HAL_setTrigger(halHandle,ignoreShuntNextCycle,midVolShunt);
}
GPIO_setHigh(halHandle->gpioHandle,TRIP);

--------------------------------------------------------------------------------------------------------------------------------------------

If I use run mode instead of DEBUG in instaspin, what code patches are inserted and what are deleted - especially in initialization of PWM? Is there anything else I can check which might be causing this phenomenon?

For debugger, we have an inhouse developed card, which uses circuit in LAUNCHXL-F28027 card with FT2232H chip. I think it equivalent of XDS100V2 debugger.

Milind Bapat said:

If I use run mode instead of DEBUG in instaspin, what code patches are inserted and what are deleted - especially in initialization of PWM? Is there anything else I can check which might be causing this phenomenon?

No any difference if you are using the project with the same build configurations.

Milind Bapat said:

For debugger, we have an inhouse developed card, which uses circuit in LAUNCHXL-F28027 card with FT2232H chip. I think it equivalent of XDS100V2 debugger.

Do you initialize all of the key variables in your project?

Thanks. Yes, i do. 

Any update on my issue TI team?

Do you use the CSM on this device? And are using the isolation JTAG debugger?

If you have initialized all of the using variables, seems like there is any further update for you if you didn't use the CSM.

Milind Bapat said:

If I use run mode instead of DEBUG in instaspin, what code patches are inserted and what are deleted - especially in initialization of PWM? Is there anything else I can check which might be causing this phenomenon?

No difference for InstaSPIN codes in ROM.

What is CSM? The debugger is isolated. 

"Dual-Zone Security Module" It's used to set the security password for secure memory blocks protection. You can find more details about this in F2805x datasheet and Technical Reference Manual.

Did you add any functions in the ISR? Is the adding function inline type? Or an external function?

Thanks for the clarification, yes, I have added further code in the ISR primarily code patches from LAB10A for reconstruction of current values.

I did some testing using a free digital output pin in "run mode" and checked the value of 

halHandle->pwmHandle[0]->CMPA variable and flashed a digital pin when the value is zero. I found out that the value is zero at the time and after PWM output is having 100% high duty cycle. So, it is a mystery why output turns low for just one cycle before going high completely. This doesn't happen in debug mode.

Can you suggest some probable things to check for this phenomenon? Is something like cycle skip is happening? If yes, what can I check?

Another thig which I observed in "Debug mode" is that. the halHandle->pwmHandle[0]->CMPB (B compare register) which should always be zero, keep wobbling with small value from 0 to 80 inside watch window, when  HAL_writePwmData(halHandle,&gPwmData); function is called (the value doesn't wobble if this function is commented) to update PWM even though Inside the code there is no instruction to change CMPB register.

Can you please suggest few things for me to test?

1. Disable the overmodulation and current reconstruction first to see what happens.

2. Limit the modulation index to 0.57, and enable overmodulation and current reconstruction see what happens.

3. Limit the modulation index to 0.66, and enable overmodulation and current reconstruction see what happens.

If case 1 is ok, but case 2 and case 3 are bad, you have to check the overmodulation and current reconstruction algorithm.

If case 1 and case 2 are ok, but case 3 is bad, you have to check the sampling current signals.