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.

TPL9202 SPI Relay driver problems

Other Parts Discussed in Thread: TM4C123GH6PM, TPL9202

I have written a library for  the TPL9202 Relay driver  using TM4C123GH6PM MCU (Tiva launchpad )

The TPL9202 has an 8 bit register .Each bit corresponds to 8 output pins of the TPL .
 
This is how i have configured the SSI port on the Tiva

SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
GPIOPinConfigure(GPIO_PA2_SSI0CLK);
GPIOPinConfigure(GPIO_PA3_SSI0FSS);
GPIOPinConfigure(GPIO_PA4_SSI0RX);
GPIOPinConfigure(GPIO_PA5_SSI0TX);
GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_3 |GPIO_PIN_2);
SSIConfigSetExpClk(SSI0_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,SSI_MODE_MASTER, 500000, 8);
SSIEnable(SSI0_BASE);

 

I use the SSIDataPut() to pass uint8_t register values as follows

uint8_t w_reg(uint8_t Relay_reg,uint8_t relay_pin,uint8_t state)
{
	if(state==0)
	{

	  Relay_reg^=relay_pin;
	}

	else if(state==1)
	{
		Relay_reg|=relay_pin;
	}

SSIDataPut(SSI0_BASE,Relay_reg);

return Relay_reg;
}

My main() is like so ,

 int main(void)
{
  uint8_t relay_reg=0x00;

  SysCtlClockSet(SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN| SYSCTL_XTAL_16MHZ);

	    SPIEnable(SSI1_BASE);
	   relay_reg= w_reg( relay_reg,RELAY_PIN_4,1);
	    while(1){

                }
}

WHere relay_Pin_4 = 0x08

 

The problem is that I am not getting any output on the pins .
Am i properly passing the register values ?Have is configured the SSICOnfigSetExpCLk() correctly ?

 

 Also , i have shorted the ~RST and BO pins on the TPL .

  • It's good that you provided a link to your SIPO device - speeds/eases assistance.  Indeed - looks like a very nice part for your application.  (providing the relay coil's targeted are w/in that 150mA spec)

    Quickly - see that EN1 must be held low for serial input to impact your device outputs. (Pg 7 TLP manual)  No mention of your treatment of EN1 appears - your posting...

    Pg 8 - TLP manual - notes that NCS must be driven and held low and that SCLK - clocks your presented MOSI data - upon each rising edge.  Have you double checked that your chosen, "SSI_FRF_MOTO_MODE_0" is in full compliance?  (i.e. NCS low thruout & data valid @ rising clk edge?)

    Am suspicious of your, "have shorted the ~RST and BO pins."  BO is described as an input and if treated incorrectly may, "disable all outputs."  (Pg 4 TLP manual)  Note the functional block dia. (Pg 3) shows BO tied to Vin thru a voltage divider and /RST pulled up to 5V. 

    Suspect your compliance w/ that block dia & proper treatment of EN1 will achieve your objective.

  • Merci monsieur !

    So there isn't anything wrong with my code ?
    Have I performed the register write via SSIDataPut() properly ?
    I have connected SSI0FSS to the NCS pin of the TPL .Since it is pulled low  during write processes  ,i have used the Freescale Spi frame format .But i just realized that i should have set SSI_FRF_MOTO_MODE_0 as SSI_FRF_MOTO_MODE_1 as you rightly pointed out 

    I have kept EN1 low .
    Someone in another TI forum had suggested to tie the BO to ~RST . I shall supply it with some voltage off of a voltage divider from VIN and see if it would help . The TPL has a 5V Out , should i tie it to BO instead ?Anyhow ,I'll get back to you after trying all that you have suggested .I will try what you said asap and verify your answer .

     

  • Just wanted to clarify a few more things .

    My selection of
     SSI_FRF_MOTO_MODE_0  seems correct to me  , as according to the datasheet ,the driver expects input data to be valid at rising edge .FSS is also handled accordingly  (held low during transmit) .

    WRT page 7 of the datasheet ,if En1 is left open or grounded,the Pin1 is controlled by the register ,if it is held high then Pin 1 is high regardless of the register value .This(EN1) probably isn't the issue .

    I might be erring with the BO and ~RST .  
    I have also given VIN 9V so that isn't the issue either . 

    From pin 1 (BO_OUTZ ) i get voltage varying between 3.5 to 4.5 V ,this after I set EN1 high ,Low and after feeding BO with 5 V from pin 18 of the TPL.

     

  • A few additional observations and questions to cb1's.

    • Regardless of what the data sheet says about the floating input being defined I'd set it explicitly for initial testing.
    • Have you checked the output from the micro with an oscilloscope?  Using an IC you have not used before to debug the communications with another IC you have not used before is a little bit of a high wire act.  The first step should be to verify that all three channels of the SPI output are behaving correctly and in-phase with one another appropriately.  I've not used them but there are inexpensive USB logic analyzers that might work if you are not properly equipped.
    • I agree BO connected to RST should work provided you are pulling them high.
    • How are you measuring the output?  You do realize this device sinks current?

     

    Robert

  • Now that you have mentioned ,I'm doubtful of my measurement as well ..(I hadn't realized until now that TPL9202 sinks current )
    I'm measuring the Voltages on the pins with a simple multimeter ,
    I shall use the O'Scope as I'm not getting required results .
    But can you verify if the way in which I am sending data via SSIDataPut() is correct ?
    Have i done all the initializations correctly ,and have i configured the ssi correctly by using
    SSIConfigSetExpClk(SSI0_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,SSI_MODE_MASTER, 500000, 8);
    Correctly ? 
    (Am i right in passing hex values as registers  ,eg. 0x04 is pin 3 ) 

  • Robert Adsett said:
    • I agree BO connected to RST should work provided you are pulling them high.

    This reporter may be especially thick (today & yesterday) but I do not believe this is correct!  By my (repeated) read of the SIPO data sheet - and the block dia "functional hookup" - pin BO will disable the device's outputs if it is set to too high a voltage.  And - if you've followed the schematic per that functional hookup - /RST is pulled up to 5V - thus any marriage of /RST (i.e. 5V) to BO will disable each/every of your device outputs!   And - that seems outside of your objective...

    Indeed I noted that yours was a sinking device (as most such are - recall old Sprague, nee Allegro - 7 channel darlington current drivers UDN/ULN).  During test the insertion of simple 3-10K pull-up Rs - each output - will clearly illustrate the output toggle - if any...

    Poster Robert (per usual) makes thoughtful comments although the scope to me seems bit overkill - simple Led cathode tied to device output - anode @ 3-5V w/series R - should be, "good for Gov't (over-taxed) work..."

    I'd add one final point - KISS is too often over-looked - yet always my (and group's) first choice.  As you repeatedly question your SPI mastery/understanding - eliminate it for now!  Instead - simply present data via normal gpio pin - and provide a rising edge (i.e. spi clk) via 2nd gpio pin - both "escaped" from any/all complications invoked by SPI.  (of course tie CS low or use 3rd such gpio to manage)  Once you've verified the SIPO device's performance - time then to move to SPI - and fight that battle once you're better armed...  Speed of bit toggle - and "efficiency" of SPI (ha!) - should not be your interest at this moment.  KISS is far better friend - proven repeatedly...

  • I think you are reading the data sheet backwards CB.  Brown Out is to detect undervoltage conditions.  The comparison level is noted in the diagram as 1.2V and in the datasheet as 1.3V so a 5V level should be sufficient.  I'd want more realistic for production but as a test level it should be fine.

    I do agree a 'scope on the output is probably overkill.  Might be useful in a last resort case to check for glitch outputs but otherwise a dmm across an appropriate load or an LED/resistor should work on the output side and long as you keep the rate of change sufficiently low.

    I was suggesting the 'scope for the SPI outputs. 

    As far as KISS, in the case of the SPI peripheral I actually found that easier to use than bit banging but that's a matter of perspective.  In any case I'd want to make sure the output worked before I worried about the response of the driver IC.

    Robert

  • Rakshit Ramesh said:

    Now that you have mentioned ,I'm doubtful of my measurement as well ..(I hadn't realized until now that TPL9202 sinks current )
    I'm measuring the Voltages on the pins with a simple multimeter ,
    I shall use the O'Scope as I'm not getting required results .
    But can you verify if the way in which I am sending data via SSIDataPut() is correct ?
    Have i done all the initializations correctly ,and have i configured the ssi correctly by using
    SSIConfigSetExpClk(SSI0_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,SSI_MODE_MASTER, 500000, 8);
    Correctly ? 
    (Am i right in passing hex values as registers  ,eg. 0x04 is pin 3 ) 

     

    The code looks reasonable.  The question is how does the SPI output differ from expectations?  Do not jump too far ahead you will get lost.

     

    Once you've confirmed the SPI output is correct you can concentrate on whay the driver IC is not responding as you think it should.

    Once you confirm the SPI output is not correct you can concentrate on why it is not correct. 

    Classic divide the problem in two and figure which 1/2 has a problem.  Fix that and look for more.  I know you know I'm right, you are just impatient :) I've been there and going fast can slow you down a lot.

     

    Robert

  • Looks to be the case Robert - here's how I came to that conclusion: (this Pg 4, TPL data sheet:)

    "The open-drain power-on reset (RST) pin remains low until the regulator exceeds the set threshold, and the timer
    value set by the capacitor on the reset delay (RDELAY) pin expires. If both of these conditions are satisfied, RST is
    asserted high. This signifies to the microcontroller that serial communications can be initiated to the TPL9202.

    The brown-out (BO) input is a resistor divided from the input supply and is used to determine if the supply
    voltage drops to undesired levels. If the input drops below the programmed value, BO_OUTZ is pulled low, and
    all outputs are disabled."

    As poster reported, "No output" - and functional block dia. showed a clear divider network @ BO - I made that connection.

    Note now that the, "care/handling" of EN1 pin impacts output 1 only - thus EN1's treatment should not prevent any other output from performing.  (I can't recall any such past creation of "single output gated" enable)  Thanks for your BO clarification...

  • I'm really sorry for prolonging this discussion to this extent !
    Turns out the manner in which i was measuring the output was wrong ,which I realized after knowing that TPL9202 is of sink type .The BO wasn't an issue .
    I followed CB's advice of measuring off of a pullup and verified the output off of an LED .
    Thank you all for your prompt replies . 

  • Excellent. 

    We've all overlooked such things at some point.  I missed that EN1 only affected OUT1 until CB pointed it out.

    Although drivers aimed at automotive market are usually sourcing drivers because of the ways automobiles are wired, there are real performance/cost advantages to building sinking drivers so it's something I usually check.

    BTW if you are using these to drive relays make sure you have proper snubbing. I didn't see any during my quick data sheet check.

    Robert

  • Excellent times 2!  And thank you for your instant follow-up - always satisfying...

    And - very neat that you awarded, "joint verify custody" - both Robert & this reporter!  (we both appreciate)

    For your future test/analysis - may serve you to build a small board w/8 Leds so that you can verify performance via the pattern of "walking 1s & 0s" - instantly identifies any outputs stuck "on or off."  (or - more likely - program miscues)

    Remember that your relay coil returns to ground @ this TPL device - and that the other end of the coil goes to your V+ and that V+ must be, "w/in V range" of the TPL output V.  (data sheet will reveal)  As Robert says - when that coil "releases" an inductive kickback will occur - if not protected w/in TPL you'll need to add the snubber (at least a diode) to limit that output V rise...

  • One small caution on using a diode only suppression circuit on the small relays this kind of drive is designed to drive.

    Some time ago a relay company (Clare maybe?) published an app note on the effects of suppression circuits on relay performance.  They especially noted that with a diode only suppressor circuit (diode in reverse bias across the coil) the time to open was significantly longer and had therefore a much higher likelihood of the relay tips welding.

    Robert