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.

Using Hall Effect Sensors and FAST Encoder

Other Parts Discussed in Thread: MOTORWARE, DRV8301-69M-KIT

I've heard a few people hint at the possibility of hall effect sensors being introduced in the upcoming Motorware 16 release, specifically with the F28069M.

I've got an application that is using a F28027F and was wondering if it would be possible to use the standard CAP inputs (27F only has one eCap input) to sample the hall effect sensors (3 inputs). Our application is looking for increased low RPM performance. My intent is use the halls for low speed operation and to then transition to FAST once a sufficient speed has been reached.

Does anyone have any experience integrating hall effects with Instaspin in this manner and if so are you using the eCap inputs to do this, the standard capture/compare inputs, or something different? Any insight into this would be greatly appreciated.

Thanks,

  • Drew,
    yes, an example of hall start-up with transition to FAST will be included with MW 16.

    we demonstrate this project on DRV8301-69M-KIT because this is the most common kit used with the higher current applications that may require hall sensor based start-up.

    for this kit the CAP1/2/3 signals are brought out to header 10. The signals routed to the controlCARD interface go GPIO40/41/42. While you can use eCAP for this purpose we are just using the GPIO qualification.

    // CAP1
    GPIO_setMode(obj->gpioHandle,GPIO_Number_40,GPIO_40_Mode_GeneralPurpose);
    GPIO_setDirection(obj->gpioHandle,GPIO_Number_40,GPIO_Direction_Input);

    // CAP2
    GPIO_setMode(obj->gpioHandle,GPIO_Number_41,GPIO_41_Mode_GeneralPurpose);
    GPIO_setDirection(obj->gpioHandle,GPIO_Number_41,GPIO_Direction_Input);

    // CAP3
    GPIO_setMode(obj->gpioHandle,GPIO_Number_42,GPIO_42_Mode_GeneralPurpose);
    GPIO_setDirection(obj->gpioHandle,GPIO_Number_42,GPIO_Direction_Input);



    and in the main ISR

    gHallState = (~HAL_readGpio(halHandle,GPIO_Number_40) & 0x1) << 2;
    gHallState += (~HAL_readGpio(halHandle,GPIO_Number_41) & 0x1) << 1;
    gHallState += (~HAL_readGpio(halHandle,GPIO_Number_42) & 0x1);


    HALLBLDC_run(hallBldcHandle,gHallState);
    gHallAngle = HALLBLDC_getAngle_pu(hallBldcHandle);

    where the angle being produced is 0, 60, 120, 180, 240, or 300 electrical
  • Chris,

    Thanks for the insight on this. This concept makes perfect sense. I believe there is a function that you can use to seed the fast observer with an angle (CTRL_setAngle_pu). Would it be best to use that function to seed the observer angle or would another approach be better to set the startup angle?

  • Drew,
    see this thread
    e2e.ti.com/.../1765621

    we use this logic to determine if we use the HallAngle or FAST

    if(_IQabs(speed_pu) < _IQmpy(gBldcToFastSpd_low,gSpeed_krpm_to_pu_sf))
    {
    gFlagBldc = true;
    angle_pu = gHallAngle;
    }
    else
    {
    gFlagBldc = false;
    angle_pu = angle_est_pu;
    }
  • Which lab project are you referring to in your examples (proj11 maybe)? Also, we are a little bit constrained on GPIO pins at the moment, do you see any problem using the AIO pins instead of a GPIO pins as inputs for the hall effect sensors? I realize we may have to do some of our own driver support instead of using the built in hal GPIO functions.

  • this will be proj_lab11e in the next MotorWare version. It is based on proj_lab11/11a

    I would guess that can be done, sure
  • Thanks for the information, I get the gist of what is going on now. I'll see what I can come up over here between now and when Motorware 16 lands.