This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28035: ILPFCKIT: Conflicts in Software & User Manual + Software Issue

Part Number: TMS320F28035
Other Parts Discussed in Thread: SFRA

Hello Experts,

I am referring to the User Guide for ILPFCKIT software SPRUI55. In section 5.1 (Page number 20) it is mentioned that duty variable DutyA is used to set duty cycle in debug mode. But for incremental build option 1, in the software ILPFC_ISR_wFRA ISR function assigns value to this DutyA variable and it is controlled by SFRA and DutyA_DC variable. DutyA not user controlled.

Another observation is PWM module startup duty cycle is maintained at 50% is there any specific reason?. Also when the controller is operated in standalone boot from flash mode DC bus over voltage fault is triggered leading software to Trip the PWM outputs at startup as there will be junk data in ADC result registers during startup( This is observed by supplying external power to the control section of the kit). Not able to get PWM output in standalone mode. In debug mode also, for the first time all the watch variables show junk data then on subsequent debug session everything runs normally. In all cases LED blinking is observed proving successful code execution in both mode. Is there any specific reason or possible fix for the problem?

Thanks and Regards

  • To debug the software I toggled a GPIO in Secondary ISR executed at 10kHz rate (OV protection is implemented here). I found that all the ADC related variables are not initialized while declaring that may be the reason for junk data at startup. It is observed that 10kHz ISR execution is started before the 100kHz fast ISR at startup leading to OV protection and PWM trip as Vbus variable is uninitialized. ISR GPIO toggling captured data is attached. So to fix the junk data problem in the declaration section of Vbus, initialized it to zero (volatile long Vbus=0) now the problem is fixed PWM output is observed at both boot modes of the controller. I'm working on why the slow ISR is executed first and then fast ISR INCREMENTAL_BUILD =1. Another observation is first GPIO toggle ON state of 10kHz ISR is small and then it is of 50% duty.ISR GPIO Toggle

    Purple- 10kHz ISR; Blue- 100kHz ISR

    Regards

  • Hi,

    In section 5.1 (Page number 20) it is mentioned that duty variable DutyA is used to set duty cycle in debug mode. But for incremental build option 1, in the software ILPFC_ISR_wFRA ISR function assigns value to this DutyA variable and it is controlled by SFRA and DutyA_DC variable. DutyA not user controlled.

    I took at look at the user guide. It says you can manually change the dutyA under build 1 which is the open loop. So I suppose the SFRA are referring to build 2 and may control the dutyA.

    Another observation is PWM module startup duty cycle is maintained at 50% is there any specific reason?.

    This is probably due to we didn't implement the soft start

    For the standalone operation, which device are you using?

    Regards,

    Chen

  • Hello,

    I'm referring to latest version of ILPFCkit software Ver1.3. I have gone through all versions provided in the controlSUIT. In version 1.0 it is true that in open loop mode DutyA controls the duty cycle. In rest of the versions it is indirectly controlled by DutyA_DC variable in SFRA. So I changed DutyA_DC to control the duty cycle in open loop. May be SFRA is added in the later versions and user guide is not updated. In open loop (BUILD 1) also SFRA is added to get open loop/plant transfer function.

    Regarding 50% duty cycle, It has been configured intentionally in the PWM module config file. So, to test my kit I modified the config so that duty will remain 0 during startup to avoid undesired operation. By observing the software, soft start is implemented in BUILD 3 after reaching 160V Vdc. 

    Another issue was in open loop mode PWM output was forced to 0 during startup, which I explained in previous reply. It was due to variable initialization issue. in BUILD 3 all the important variables are correctly initialized and Vbus is used to detect OV only in BUILD 1 and 2.  ADC startup is normal and it has no issues but uninitialized variable caused OV protection to activate and forcing PWM to 0 state.

    At the moment I have successfully built and flashed the software in all the incremental build options and all hardware test results are verified in both debug and standalone mode. I'm using ISO DIMM control card housing F28035 controller which was included in ILPFCKit.

    Regards

  • Hi Anup,

    Thanks for your summary and good to know that you have figured them out.

    Regards,

    Chen