• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 525 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LAUNCHXL-F280049C: Sharing SPI with DRV8320 in Launch XL F280049C and DRV8320-BOOSTXL

Kustaa Nyholm
Expert 2005 points
Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: DRV8320

Hi,

I need to share with some other peripherals  the SPIA which is connected to the DRV8320.

But as soon as I do anything with the SPIA_STE pin (to prevent the slave select to DRV8320) the Instaspin FOC stop doing anything.

If I add these two instructions to the main loop of is07_speed_control.c main loop, the motor no longer runs:

    GPIO_setPinConfig(GPIO_57_GPIO57); // This should prevent the STE signal

// here I will add the code to talk to my peripherals

    GPIO_setPinConfig(GPIO_57_SPISTEA); // This should restore the STE/SPI functionality

This 'trick' worked with F28027.

But with F28049C nothing seems to restore the FOC functionality.

Even re-initializing the SPI with the HAL layer methods prevents the FOC from doing its business.

And even if above are not in the loop, even if I do them once before I enter the mainloop, the problem appears.

I'm out of ideas.

wbr Kusti

  • 0
    TI__Guru** 116210 points

    The GPIO should be set to high as the below codes.

    GPIO_setPinConfig(GPIO_57_GPIO57);
    GPIO_writePin(57, 1);
    GPIO_setDirectionMode(57, GPIO_DIR_MODE_OUT);
    GPIO_setPadConfig(57, GPIO_PIN_TYPE_PULLUP);

    And all of the related functions of the DRV8320 can't be called if the SPIA_STE is configure to GPIO to disable the selection of DRV8320.

  • 0 in reply to Yanming Luo
    Expert 2005 points

    Hi,

    thank you.

    As I tried to explain, above does not work.

    Just doing this (below) once before the main loop of  'is07_speed_control.c' from Instaspin labs prevents the FOC from working.

    I copy pasted your suggestion and copy pasted the initialisation from the hal.c  to restore the pin function

    so one would think it works. But does not.

    So I'm not getting anywhere...

        // Disable SPISTEA

    GPIO_setPinConfig(GPIO_57_GPIO57);

    GPIO_writePin(57, 1);

    GPIO_setDirectionMode(57, GPIO_DIR_MODE_OUT);

    GPIO_setPadConfig(57, GPIO_PIN_TYPE_PULLUP);







    // Restore SPISTEA

    // GPIO57->SPIA-CS for J1/J2 connection

    GPIO_setMasterCore(57, GPIO_CORE_CPU1);

    GPIO_setPinConfig(GPIO_57_SPISTEA);

    GPIO_setDirectionMode(57, GPIO_DIR_MODE_OUT);

    GPIO_setPadConfig(57, GPIO_PIN_TYPE_STD);

  • 0 in reply to Kustaa Nyholm
    Guru 56093 points

    Hi Kustaa,

    Why not simply use SPI-B booster headers open/free for your other peripheral business.

  • 0 in reply to Genatco
    Expert 2005 points

    Hi Gl,

    thanks for the suggestion.

    Two reasons:

    a) it would require hardware change (not a big deal but sill)

    b) in the next phase that is reserved for host communication so I would have to come back to SPI A issue in a week or two

    But! I've located the actual problem!

    When we moved from LAUNCHXL F28027 to F280049C we did not spot that one of the GPIO pins that we used to select

    one of the SPIs is not available as output anymore and so was basically floating and thus the Slave Select for one of the

    SPI devices was sometimes active depending on timing which caused the SPI data to be corrupted and thus prevented

    proper function of the DRV8320.

  • 0 in reply to Kustaa Nyholm
    TI__Guru** 116210 points

    Actually, the DRV8320 device doesn't occupy the SPI always, it just uses SPI to configure the control registers during initializing its interface in the example lab. Even the DRV8320 doesn't need to use the SPI if you are using the default value of the control registers.

    Did you just call HAL_enableDRV once during the initialization? Can you monitor the ENABLE and nFAULT pins to see that happens if you disable the SPI for DRV8320?

  • 0 in reply to Yanming Luo
    Expert 2005 points

    Thanks, yes, the DRV8320 is only initialised once but because of the floating CS of other SPI devices this failed. 

  • 0 in reply to Kustaa Nyholm
    TI__Guru** 116210 points

    If you are using the default control parameters of DRV8320RS and remove all of its related functions, the DRV8320RS on launchPad-F28-49 can work well even though you don't use the SPI to configure its control register. You might check if you change other GPIOs for DRV8320RS, such as the EN_GATE pin.