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.

TMS320C28346 ControlCard - SPId issues

Dear all,

In the frame of a R&D project, I need to use up to 2 C28346 ControlCard as SPI slaves. Each of the ControlCard is attached through the DIMM168 connector to a home-made PCB on which are the powersupplies and so on. The home-made PCB also takes care of the SPI slaves connection: A master board sends, through a  flat cable, the SPI signals to the first slave board where they goes to the DIM168 connector and to the second slave board, also through a flat cable.

I am using the SPId module of the C28346 on pins shared with GPIO  48 to 51. the configuration is as follows:

//----------------------------- SPI D---------------------------------------------
    // Used to communicate with the CPU (master board)
        EALLOW;

        /* Enable internal pull-up for the selected pins */
        // Pull-ups can be enabled or disabled disabled by the user.
        // This will enable the pullups for the specified pins.
        // Comment out other unwanted lines.

            GpioCtrlRegs.GPBPUD.bit.GPIO48 = 1;    // Disable pull-up on GPIO48 (SPISIMOD)
            GpioCtrlRegs.GPBPUD.bit.GPIO49 = 0;    // Enable pull-up on GPIO49 (SPISOMID)
            GpioCtrlRegs.GPBPUD.bit.GPIO50 = 1;    // Disable pull-up on GPIO50 (SPICLKD)
            GpioCtrlRegs.GPBPUD.bit.GPIO51 = 1;    // Disable pull-up on GPIO51 (SPISTED)

        /* Set qualification for selected pins to asynch only */
        // This will select asynch (no qualification) for the selected pins.
        // Comment out other unwanted lines.

            GpioCtrlRegs.GPBQSEL2.bit.GPIO48 = 3;   // Asynch input GPIO48 (SPISIMOD)
            GpioCtrlRegs.GPBQSEL2.bit.GPIO49 = 3;   // Asynch input GPIO49 (SPISOMID)
            GpioCtrlRegs.GPBQSEL2.bit.GPIO50 = 3;   // Asynch input GPIO50 (SPICLKD)
            GpioCtrlRegs.GPBQSEL2.bit.GPIO51 = 3;   // Asynch input GPIO51 (SPISTED)

        /* Configure SPI-D pins using GPIO regs*/
        // This specifies which of the possible GPIO pins will be SPI functional pins.
        // Comment out other unwanted lines.

            GpioCtrlRegs.GPBMUX2.bit.GPIO48 = 3;   // Configure GPIO48 as SPISIMOD
            GpioCtrlRegs.GPBMUX2.bit.GPIO49 = 3;   // Configure GPIO49 as SPISOMID
            GpioCtrlRegs.GPBMUX2.bit.GPIO50 = 3;   // Configure GPIO50 as SPICLKD
            GpioCtrlRegs.GPBMUX2.bit.GPIO51 = 3;   // Configure GPIO51 as SPISTED

         /* Configure GPIO37 for be high to put the SRAM mounted on the controlboard in power-down mode
         in order to avoid conflict with SPI signals*/
            GpioCtrlRegs.GPBPUD.bit.GPIO37 = 1;        // Disable pull-up on GPIO37 (nCE_H)
            GpioCtrlRegs.GPBQSEL1.bit.GPIO37 = 3;      // asynchronous GPIO37
            GpioCtrlRegs.GPBDIR.bit.GPIO37 = 1;        // GPIO37 is an output
            GpioDataRegs.GPBSET.bit.GPIO37 = 1;        // GPIO37 is HIGH


            SpidRegs.SPICCR.bit.SPISWRESET = 0;                    // Reset SPId during configuration
            SpidRegs.SPICCR.bit.CLKPOLARITY = 0;                // Data output @ rising edge and input @ falling edge (CLK_POLARITY = 0)
            SpidRegs.SPICTL.bit.CLK_PHASE = 0;                    //
            SpidRegs.SPICCR.bit.SPICHAR = 15;                    // data transmitted in 16 bits

            SpidRegs.SPICTL.bit.OVERRUNINTENA = 0;                // Disable receiver overrun interrupt
            SpidRegs.SPICTL.bit.MASTER_SLAVE = 0;                // configured as a slave
            SpidRegs.SPICTL.bit.TALK = 1;                        // Enable transmission
            SpidRegs.SPICTL.bit.SPIINTENA = 0;                    // SPId interrupts disabled

            SpidRegs.SPIBRR = 14;                                // LSPCLK = 75 MHz
                                                                // SPICLK = 75 MHz /(14+1) = 5 MHz

            SpidRegs.SPIPRI.bit.SOFT = 1;                        // Free run
            SpidRegs.SPIPRI.bit.FREE = 1;

            SpidRegs.SPICCR.bit.SPISWRESET = 1;                    // End of configuration

            SpidRegs.SPICTL.bit.SPIINTENA = 1;                    // Enables SPId interrupts
            PieVectTable.SPIRXINTD  = &SpiInterrupt;              // Map the SPI_D RX interrupt to the ISR
            PieCtrlRegs.PIEIER6.bit.INTx7 = 1;                    // Enables SPIRXTINTD in the PIE: Group 6 interrupt 1
            IER |= M_INT6;                                        // Enable interrupts from group 6

    EDIS;

So far so good, but here is my issue: When I am using only one SPI slaves, everything goes perfectly well. But as soon as I connect a second SPI slave board, the communication between the master board and the first salve, and only the first one, goes bad. The first slave seems to skip bits and therefore does a lot of bad things with the received information.

I have already spent a lot of time on this issue (almost 2 weeks) and I am reaching the end of my time budget. So has anyone already experienced something like that???

I have already been able to rule out few possible explanations:

a) I exchanged the physical boards (Slave 2 goes to slot 1 and Slave 1 to slot 2) => same result

b) I decrease the clk speed down to 10 kHz => same result

c) I checked every single signals of the SPI bus on both slave boards (on the DIMM168 connectors) => can't find anything wrong (the edges are steep, the logical levels well defined, the timing adapted)

d) I have seen that the SPId pins I am using are shared with a Flash memory (U20) on the ControlCard. I put the memory pins in high-z state by putting C28346 GPIO37 HIGH => same results. I unsoldered U20 => same results

e) I connected both slave boards but talked only to the first one => same results

f) I changed the connecting flat cables => same results

g) I changed the ControlCards => same results

h) I connected both home-made slave boards but with no ControlCard on the second => the communication goes well again but that doesn't really solve my problem since I can't use both at the same time.

Therefore, I have been able to determine that the issue it related to the ControlCard itself and to my home-made hardware, since connecting a second ControlCard puts the first one into trouble.

Nevertheless, I have not been able to figure out what is wrong as, since I unsoldered U20 on the ControlCard, the SPI signals are not shared with anything else than the C28346! I have looked in the silicon errata but was unable to find any problem related to SPId.

I can provide the hardware layout and schematics by e-mail but I don't want to broadcast them on the net.

My next step is move the SPId to SPIa pins (GPIO 16 to GPIO19), which are not shared with anything else on the ControlCard and use buffer to "isolate" the slaves from one-another. Nevertheless, hardware changes are time consuming and I wanted to make sure it is the only solution.

So please, does anyone have a idea?

Many thanks in advance to anyone able to help me :)

Christian

  • Hi Christian,

    From my understanding, your setup is something like the below:


    Master board                           | Slave board 1
    ____________________                   |
                        |                  |
     SPI1  --->  Slot-1 |===flat cable-1==>|--> SPID of C2K-1 (cCARD1)
     & Power/GND        |                  |___________________________
                        |                  ____________________________
     SPI2  --->  Slot-2 |===flat cable-2==>|--> SPID of C2K-2 (cCARD2)
     & Power/GND        |                  |
    ____________________|                  |
                                           | Slave board 2



    Does each C2000 gets its own separate SPI from the master (as in the above)? Or is the SPI shared between the two C2K devices?  Otherwise am I pretty much correct in my diagram?

    -It is not abundantly clear to me what, 'same results' means in experiments a) through g)
    -I might recommend experimenting more on item e).  Perhaps add one signal wire at a time until the system breaks.  This may lead you toward a power supply overdraw issue or something like that.


    Thank you,
    Brett

  • Hello Brett,

    Thanks very much for your quick answer!

    I drew a rough schematic to make the setup more clear: Both slaves are sharing the same SPI bus. The destination of a given communication is decided by the state of the active-low slave select signals (nSS). This is due to the fact the SPI master chip doesn't enough available pins to use a separated SPI bus for the two slaves. Moreover, the CLK and MOSI signals are directly connected to both slaves and master. The MISO signals is buffered with 7407 (open-collector buffers, unshown on schematic) to avoid conflicts in the line.

    - "same results" meant that slave 1 didn't always receive what has been sent (skipping bits) while the communication went perfectly between master and slave 2. I should have been more clear.

    - Concerning overdraw in power-supply, I have ruled out this explanation since the three boards have their own power-supply, sharing the 0V through the  flat cable. Moreover, I have seen no fall of the signal level (3.3V) or the power supply (5V) during the problem.

    4846.SPIConfig.pdf

    I hope I have been able to make the situation more clear. Do you see a flaw in my design? I have used such a SPI configuration in many situations (not with ControlCards) and always been successful.

    Thanks again for you help!

    Christian

  • Christian,

    What you say seems logical now that I understand the situation better.

    --

    I'll think a bit more on this, but the one think that comes to mind is pull-ups.   The other is to confirm what you say you've done - make sure the signals are right coming to slave 1 (especially nSS1)

    Can you try experimenting with the internal pull-up settings?  I would enable the pull-up on both nSS lines.  Maybe CLK can be experimented with too.


    Thanks,
    Brett

  • Christian and Brett,

    I don't think pullups would cause any issues here.  SPI busses are typically driven with a push-pull.  I2c is where pullups start to become important.

    I'm curious about the tests that you did.  You say that swapped which slot each of the slaves was in...could you elaborate on that?  By slot do you mean the spot on the flat cable the slave was plugged into?  Have you tried swapping around the controlCARDs?  I think the key to solving this issue is finding the offending hardware.

    BR,

  • Christian,

    I might not have followed this through correctly yet, but what is the master board here? why can't be there something wrong with the master board, especially the nSS1 and nSS2 signals? how are these controlled, can you configure them as regular GPIO (instead of SPI signals) and pull only the needed one LOW using GPIO Data registers while you pull the other one HIGH?

    did you scope the SPI signals and see what's going on? is the slave missing bits because they aren't there on bus or ??

     

    Best Regards

    Santosh

     

  • Dear Brett, Santosh and Trey,

    Thanks a lot for your help. Once again, TI employees are always there when I need help with my design.

    - Concerning the signals integrity: I have looked at all the signals and haven't been able to spot a flaw. Moreover, the fact that the second slaves behave perfectly would indicate that the SPI signals (CLK and MOSI) are OK and that the problem would come from the nSS. Nevertheless, this signal is also perfectly clean. Moreover, it is the only signal that is not impacted by the second board connection. (I didn't record my experiment to attach scope measurements to this conversation but i swear I cheched the signalss :))

    - Concerning the slave swapping: What I did is a) plug slave board 1 instead of slave board 2 and vice-versa: still had problem with slave board 1 (slave board 1 being defined as the one directly connected to the master board) and b) exchanged ControlCards between slave board 1 and slave board 2. I still had the same results (slave board 1 skipping bits). c) replaced the ControlCards by new ones but still got the same results.

    - Concerning the master board: The master chip is one from another manufacturer (whose name I will not mention here :)) I have used it's SPI module in many designs and never encontered this kind of trouble. Moreover, I changed the master Board too and didn't gest any improvements. That is one fo the reasons why I think the problem comes from the ControlCards. The second reason being the fact the probelm occurs only when I connect a ControlCard on the second slave board.

    I have designed a new hardware prototype for the slave boards, including buffers to "isolate" slaves from oneanother. Nevertheless, I will not be able to experiment with it before 2 weeks at least. To me, that seemed to be the only way forward in my available time frame.

    I hope I have been able to provide valuable informations on my case and that it may ring a bell on TI side :)

    Thanks again for your help!

    Best regards,

    Christian