• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1216 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.

TMS320F28075: SPISOMIA problem on mappig

fiorello miotto
Prodigy 60 points
Part Number: TMS320F28075


Hello,
I'm using TMS320F28075 SPIA interface, if I map SPISOMIA on GPIO55:

    GpioCtrlRegs.GPBPUD.bit.GPIO54 = 0;  // Enable pull-up on GPIO16 (SPISIMOA)
    GpioCtrlRegs.GPBPUD.bit.GPIO55 = 0;  // Enable pull-up on GPIO17 (SPISOMIA)
    GpioCtrlRegs.GPBPUD.bit.GPIO56 = 0;  // Enable pull-up on GPIO18 (SPICLKA)
    GpioCtrlRegs.GPBPUD.bit.GPIO57 = 0;  // Enable pull-up on GPIO19 (SPISTEA)
    GpioCtrlRegs.GPBQSEL2.bit.GPIO54 = 3; // Asynch input GPIO16 (SPISIMOA)
    GpioCtrlRegs.GPBQSEL2.bit.GPIO55 = 3; // Asynch input GPIO17 (SPISOMIA)
    GpioCtrlRegs.GPBQSEL2.bit.GPIO56 = 3; // Asynch input GPIO18 (SPICLKA)
    GpioCtrlRegs.GPBQSEL2.bit.GPIO57 = 3; // Asynch input GPIO19 (SPISTEA)

    GpioCtrlRegs.GPBGMUX2.bit.GPIO54 = 0; // Configure GPIO16 as SPISIMOA
    GpioCtrlRegs.GPBMUX2.bit.GPIO54 = 1; // Configure GPIO16 as SPISIMOA
    GpioCtrlRegs.GPBGMUX2.bit.GPIO55 = 0; // Configure GPIO17 as SPISOMIA
    GpioCtrlRegs.GPBMUX2.bit.GPIO55 = 1; // Configure GPIO17 as SPISOMIA
    GpioCtrlRegs.GPBGMUX2.bit.GPIO56 = 0; // Configure GPIO18 as SPICLKA
    GpioCtrlRegs.GPBMUX2.bit.GPIO56 = 1; // Configure GPIO18 as SPICLKA
    GpioCtrlRegs.GPBGMUX2.bit.GPIO57 = 0; // Configure GPIO19 as SPISTEA
    GpioCtrlRegs.GPBMUX2.bit.GPIO57 = 1; // Configure GPIO19 as SPISTEA

it doesn't work, it seems to be locked to 0xFFFF. Take into account that SPISIMOA, SPICLKA and SPISTEA work well.
If I map SPISOMIA on GPIO59 it works as I expect.
The SPI is 1Mbaud rate.
At the same time I'm using SPIB (SPISOMIB on GPIO64) and *** (SPISOMIC on GPIO51) also and they are working without any problem.

  • 0
    Guru 30330 points
    Fiorello,

    A few comments/questions:
    - Your configuration code is correct. I am assuming that you have EALLOW before and EDIS after the block of referenced code?
    - Is SPIA a master?
    - Have you put a scope on this signal to see if the pin is toggling or not?
    - Is anything extra connected to GPIO55 on your PCB? Is this a custom board or a TI evaluation kit?
    - Have you verified that nothing changes the GPIO configuration for GPIO55 in your code elsewhere?

    Those questions should get you started, please provide a response, and let me know any other information that you may have that might help.

    Regards,
    Mark
  • 0 in reply to Mark Labbato
    Prodigy 60 points
    Hi Mark,
    - I have EALLOW ad EDIS as requested;
    - SPIA is a master;
    - the pin is toggling with the rigth signal fron the slave;
    - anything extra is connected to GPIO55 and nothing changes the GPIO configuration for GPIO55.
    I made the same for SPIB and *** with good results.
    Best regards,
    Fiorello
  • 0 in reply to fiorello miotto
    Guru 30330 points
    Fiorello,

    Can you verify that you don't have two GPIOs simultaneously configured as SPISOMIA?
    When do you see a value of 0xFFFF? is it observing the SPIRXBUF register?
    Are you using the DMA and you get this in your data buffer? is the memory region containing the receive data buffer set up for access by the CPU?

    Assuming that the pin is set up properly for SPISOMIA, the SPIRXBUF should reflect the proper state of the pin.

    You might also want to test that your pin is not damaged.
    1. Set up GPIO55 to be a GPIO output. can you drive a 0 and a 1 on the pin?
    2. set up GPIO55 to be a GPIO input. if you drive a 0 or 1 onto the pin, does the GPIO data register reflect the state of the pin?

    -Mark
  • 0 in reply to Mark Labbato
    Prodigy 60 points
    Hi Mark,

    - Only Gpio55 is configured as SPISOMIA.
    - I have seen 0xFFFF observing the SPIRXBUF register and observing a proper variable on my own interface via SCI ModBus.
    - Setting up GPIO55 to be a GPIO input I can see the GPIO reflecting the state of the pin.
    I have the same situation on two boards.

    Fiorello
  • 0 in reply to fiorello miotto
    Guru 30330 points
    Fiorello,

    I am not quite sure what the issue is here.
    If you connect SPISOMIA to SPISIMOA and do an external loopback test, is the SPIRXBUF still stuck?

    -Mark
  • 0 in reply to Mark Labbato
    Prodigy 60 points

    Mark,

    the SPIA is working with SPISOMIA in the GPIO59, why it desn't work with GPIO55?
    It seems as if the SPIA doesn't enter the GPIO55.

    Fiorello

  • 0 in reply to fiorello miotto
    Guru 30330 points
    Fiorello,

    Are you using custom hardware? Can you share the schematic of just this circuit?
    What device Package are you using? GPIO55 is not available on the 100-pin PZP package. It is only available on the 176-pin PTP package. See the images in the datasheet. www.ti.com/.../terminal-configuration-and-functions . You have mentioned that you can see the input changing when you drive it, so I do think that you are using the 176-pin PTP package, but it is worth verifying.

    Please let me know if you have verified that the same behavior is occurring if you set up the SPI in a simple external loopback mode. Configure the GPIOs as you need, then just short SPISIMOA to SPISOMIA with a wire. Make sure that the SPILBK bit is 0.

    I have verified on the bench that this pin does toggle and take SPISOMIA properly. This is a very odd problem that I have not seen before. The GPIO is working, but the SPI doesn't work on that same pin.

    -Mark
  • 0 in reply to Mark Labbato
    Guru 30330 points
    Fiorello,

    I haven’t heard from you for a few weeks, so I’m assuming you were able to resolve your issue. If this isn’t the case, please reject this resolution or reply to this thread. If this thread locks, please make a new thread describing the current status of your issue.

    Thanks,
    Mark
  • 0 in reply to Mark Labbato
    Prodigy 60 points

    Hi Mark,
    it was my mistake. It wasn't as easy to find the trouble.
    Defining EPwm9 Gpios:
    void InitEPwm9Gpio(void)
    {
        EALLOW;
        //
        // Disable internal pull-up for the selected output pins
        // for reduced power consumption
        // Pull-ups can be enabled or disabled by the user.
        // This will enable the pullups for the specified pins.
        // Comment out other unwanted lines.
        //
        GpioCtrlRegs.GPAPUD.bit.GPIO16 = 1;    // Disable pull-up on GPIO16 (EPWM9A)
        GpioCtrlRegs.GPAPUD.bit.GPIO17 = 1;    // Disable pull-up on GPIO17 (EPWM9B)

        //
        // Configure EPWM-6 pins using GPIO regs
        // This specifies which of the possible GPIO pins will be EPWM6 functional
        // pins.
        // Comment out other unwanted lines.
        //
        GpioCtrlRegs.GPAMUX2.bit.GPIO16 = 1;   // Configure GPIO16 as EPWM9A
        GpioCtrlRegs.GPAMUX2.bit.GPIO17 = 1;   // Configure GPIO17 as EPWM9B

        EDIS;
    }

    I forgot:

        GpioCtrlRegs.GPAGMUX2.bit.GPIO16 = 1;   // Configure GPIO16 as EPWM9A
        ----
        GpioCtrlRegs.GPAGMUX2.bit.GPIO17 = 1;   // Configure GPIO17 as EPWM9B
        ----

    thus defining GPIO17 as SPISIMOA input pin, this conflict with the GPIO55 configuration.
    I'm sorry for the trouble. Thanks for your help.
    Fiorello

  • 0 in reply to fiorello miotto
    Guru 30330 points
    Fiorello,

    I am glad that you were able to figure out that the GPIO mux was set up incorrectly. That is a difficult issue to find, as your GPIO55 configuration did not change. unfortunately the best way to debug this issue is to check every place that a peripheral function is brought to a different GPIO and look to see if there are any configured the same way.

    Please don't hesitate to create a new post in the future if you ever encounter more trouble.

    Regards,
    Mark