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.

Problems with migration from F28035 to F28069 in HVMotorCtrl+PfcKit based project

Hey,

I developed a hard and software based on the HVMotorCtrl+PfcKit to control BLDC Motors with the F28035 microcontroller.

Due to the need of a second QEP encoder we changed the hardware to the F28069 controller.

To adapt the software to the new hardware I changed all the used header files, the linker command files, ... as described in the sprabj2 TMS320F2802x/TMS320F2803x to TMS320F2806x Migration Overview. Additionally I changed the BLDC Sensored  DevInit, f2803xbldcpwm, f2803xhall_gpio, f2803xileg_vdc and f2803xpwmdac files to the f2806x ones found in the BLDC_Sensored Project of the DRV8312-C2-KIT_v128 found in the Control Suite software.

After fixing several compilation failures caused by the change of the header and driver files the project could be build without any errors. Although the RS-485 communikation and the SPI communikation with the new prozessor works fine. 

But when i connect a Motor to the new hardware it don´t react as expected. It seems that there is a problem in the control of the Motor with the added files.

Did someone get similar problems by migrating from 2803x to 2f806x?

Did i forget anything important by converting the project from f28035 to f28069?

Is it principle possible to use the F28069 with the same _IQ math as the fixed point f28035?

Thank you very much for your time

Regards

Joachim

  • Joachim,

    Can you explain what you mean by "the new hardware...doesn't react as expected"?  Does the motor try to spin and fail?  Or does the motor not do anything at all?

    IQmath will work on F28069 or on F28035.  (note that because the F28069 has native floating point, the IQmath functions may be converted automatically to floating point instructions; there is a setting for this (I think in the compiler).

    Most likely the issue is that because the frequency of the device has increased, the PID values no longer are tuned correctly to the motor.  It will be worthwhile to start at incremental build 1 and slowly move to a fully closed system.


    Thank you,
    Brett

  • Hey Brett,

    thank you for your answer. In the meantime the problem was solved. It hasn´t anything to do with the software, the hardwaredesigner mixed up two pins of the processor (two GPIO´s used for the Hall sensors). So the motor couldn´t spin.This question is thereby answered.

    Thank you for all the work.

    Joachim