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.

TLC59116 Changing GRPPWM causes erractic flashing

Other Parts Discussed in Thread: TLC59116F, TLC59116, MSP430F5510

Hi,

I designed and built the LED system shown in the link.

http://www.autoartisans.com/rings/Barge1a.jpg

I'm finally trying to track down a problem we ran into back in 2009/2010.  When we change the GRPPWM register from a larger value to a smaller value to dim the 12 channels we have connected to RGB and White LEDs.  The scenario is as follows.  We'll set the PWM registers to create a specific colour.  Then we may want to slowly dim this colour to dark using the GRPPWM register.  We do this by periodically sending out a smaller GRPPWM value to dim the overall intensity.  Each time we send out an IIC message with 18 bytes.  The Control/Address(0x82), 16 PWM channels and the GRPPWM value.

If, every 40mS, I send out a new GRPPWM value that is smaller by 4,  it works most of the time but there are occasional errratic flashes where the RGB channels are suddenly quite bright as it happens at the lower PWM value.  We're certain our IIC communications is functioning since we don't have any trouble changing any of the regular PWM registers.  If we did the flashes would be coloured differently. 

Needless to say the flashing is disconcerting and we've had clients comment negatively about it so I've been asked to see if we can fix it.

Thanks

John

  • For what it's worth, I see the same problem when I change GRPPWM to dim the LEDs too.  I'm leaving the individual PWM registers at 0xFF and just lowering the value of GRPPWM.

    I'm using a TLC59116F.

    Peter

  • I haven't done anything on this project for quite some time so the problem for me remains unsolved.  Ultimately the solution will be to use a different product.  Especially since TI hasn't responded to this.

    John

  • John,

    My apologies for the very late response.  I have done a bit of research and have found something that may be of interest.

    The Group Blinking register can be set up to 10.73 seconds.  If the system updates the register in the "dead time" between the long cycle, the device must finish the current blinking cycle before it will reset the internal blink counter to the new value.  This would result in a timeout before the new value appears.

    Does this explain the situation you were seeing?

    Regards,

    Dick

  • No, that doesn't explain what I'm seeing.  I'm not using blinking mode and neither is John.  We're both dimming the LEDs.

  • Peter is right.  I'm not using the blink.  The idea behind the group dim is to first set RGB LEDs to specfic values.  Say we get a nice turquoise at full intensity of the dominant RGB LED.  Now we want to dim the turquoise.  Assume for a moment that the colour is made from 255 BLUE, 240 GREEN and 40 RED.  At some point below 40 the RED LED will probably turn off.  So the total dim range of the RGB colour may only be a range of 20 before a colour shift occurs.

    So the group dim register with threoretically provide the same shade over a wider dynamic range.  We had 742 LED lamp modules.  Each lamp had 36 LEDs, 9 each of RGBW.  They all ran the same firmware and responded to CAN messages with the RGBW & I values.  In additional to being individually addressable each lamp would also respond to a global ID number so I could control all 742 lamps at once. 

    One CAN message at a 25Hz rate.  That's less than a 100uS per message one every 40mS.  If each message reduced the GROUP PWM register by say 4 then each lamp receives the message at the same time and would become dimmer over time.  That's exactly what happened but as the lamps dimmed we'd see periodic flashes on single lamps. 

    I think Dick Stacy's comments are valid but I suspect that the intensity value used by the Group PWM register can be corrupted if reloaded at the wrong time.  Instead of say 40 it gets garbage that looks like 0xFF or full intensity.  A single lamp doing that once every serveral seconds for 40mS before it's reset to the correct intensity is a tough bug to find.

     

     

     

     

  • Hi all,

    I'm working on a new design using the TLC59116, and found this thread while investigating the erratic flashes which I too have been experiencing. I have 3 RGB LEDs connected to the chip, running at various fixed colors, and ramping the GRPPWM value from 0xFF to 0x00.

    I also came across this thread:

    http://e2e.ti.com/support/power_management/led_driverslcd_bias/f/192/t/201430.aspx

    As I posted in more detail there, there appears to be a connection between this issue and the incorrectly-documented GRPFREQ register. The TLC59116 datasheet claims that this register is a 'don't care' while in PWM rather than blinking mode, but this is absolutely not the case. PWM will only work properly (ignoring the flashes) with GRPFREQ set to 0. Any other value reduces the dynamic range of the PWM, with most values resulting in 100% brightness regardless of PWM setting.

    The phenomenon which I have observed is most apparent with a GRPFREQ value of 1. At the moment when the brightness actually begins to decrease while running my test code (individual LEDs set to 0xFF and GRPPWM at 50%), the actual brightness drops momentarily, spikes back to 100%, then drops to the correct dim level. This happens consistently on every single brightness sweep at exactly the same point. Note that the erratic flashes continue to occur as well, but apparently asynchronously to these. The durations appear to be the same.

    Perhaps this info will help someone get to the bottom of this serious issue with an otherwise impressive part...

    Thanks,

    ---Karl

  • Fascinating.  A few years later and the same questions are still being asked and others are having similar problems.  Following your links backwards I arrive at my original posting. 

    I've never solved the problem. I think it's inherent inside the device.  I suspect that writing to the GRPPWM register is occurring asynchronously while it's also being used.  I don't know what the slicon looks (or perhaps VHDL code) looks like internally but here's my guess.

    The GRPPWM register is tested against the intensity counter that rolls over at 255 back to 0.  When it matches the GRPPWM register the intensity outputs are enabled or disabled.  Depends on if the counter is going up or down.  In either case, when the IIC is updating the GRPPWM location the compare operation for the actual PWM doesn't read the register because it's being changed but instead gets 0xFF.  Since the 0xFF would be the same value for 100% intensity the display of course goes fully bright.  On the next cycle through the counter the IIC update is complete and whatever value is in the GRPPWM register is now correctly retrieved for the compare.

    If I recall correctly  the GRPPWM operates at a lower frequency than the actual PWM for the individual outputs.  That's why it's probably handled differently from the individual channels. 

    The work around might be to only update the IIC information during the time the group intensity PWM output is ON.  (or maybe off).  

    My projects using this controller are on an indefinite hold at the moment so I haven't done anymore work on them but if you find anything I'd like to know.

    John Dammeyer

  • Hello,

    I can see this problem has never been resolved.

    Well, I have the same issue here...

    Everything works fine, except for periodically writing the GRPPWM register for global dimming.

    I want my leds to "glow" if you know what I mean, but the random flashing is very irritating, and more so: unacceptable...

    I am sure my IIC interface is ok: I write value to GRPPWM and immediately readback and compare... --> No problems here.

    Explanations please?

    --> I really don't want to design in another IC, not that it's so much work, but still.... 

    Best regards,

    Tim

  • Years later... I can provide another sad report of the exact same issue.

    I am using the TLC59116 to drive multiple RGB LEDs. I set the individual PWM channels appropriately and set the outputs to be controlled by PWM + GRPPWM. I set DMBLNK to 0 and GRPFREQ to 0x00, then step the value of GRPPWM up and down.

    It generally works, but with random "erratic flashing" where the brightness seems to spike.

    Does TI have a fix for this? Is it addressed at all in TLC59116F?

  • Hi Jason,

    I'll look into this. Can you share the code please? Is there a specific location/command that's causing the erratic flashing?
  • Hi Harry,

    Thanks for the response! I will put together a sample project to demonstrate the issue. I am using the TLC59116 on a custom PCB (using an MSP430F5xxx) so it might require a bit of modification to work on your platform... but I'll include as much information as possible.

    In the meantime, I can say that the issue happens upon writing any value to the GRPPWM register (0x12).
    My other registers are set as:
    MODE1: 0x01
    MODE2: 0x04
    GRPFREQ: 0x00
    Individual PWM registers at various values
    Individual LEDOUT registers set as 0xFF (all LEDs controlled by both PWM + GRPPWM)

    Thanks,

    Jason

  • Here's what I do.  I have a function that modifies the values in the array to the defaults in EEROM and sends it out to the device. There's also a function that sets the Intensity values.
    The main control might slowly change the group intensity and that's when there are the periodic flickers.

    
    
    /*
     *    Private Variables.
     */
    const unsigned char LEDInitData[] = {
        0x00,    // Register Address
        0x01,     // MODE1 Value
        0x00,     // MODE2 Value
        0x0f,    // RED0
        0x0f,    // RED1
        0x0f,    // RED2
        0x0f,    // RED3
        0x0f,    // GREEN0
        0x0f,    // GREEN1
        0x0f,    // GREEN2
        0x0f,    // GREEN3
        0x0f,    // BLUE0    
        0x0f,    // BLUE1
        0x0f,    // BLUE2
        0x0f,    // BLUE3
        0x0f,    // WHITE0
        0x0f,    // WHITE1
        0x0f,    // WHITE2
        0x0f,    // WHITE3
        0x0f,    // INTENSITY
        0x00,    // GRP FREQ
        0xFf,    // LEDOUT0
        0xFf,    // LEDOUT1
        0xFf,    // LEDOUT2
        0x3f,    // LEDOUT3
        0xD2,    // SUBADR1
        0xD4,    // SUBADR2
        0xD8,    // SUBADR3
        0xD0,    // ALL CALL
        0xE8    // IREF
    };
    
    /* * SetIntensity -- Sets both Intensity, Group Frequency and Blink Mode. * It's done together because although the data sheet says there's no * interference, if GRPFREQ is not zero then PWM doesn't work right. */ void SetIntensity( BYTE inten, BYTE freq, BYTE mode ) { DevData[1] = inten; DevData[2] = freq; Put_IIC_TL59116_Buf( GRPPWM_REG, 3, DevData ); Put_IIC_TL59116_Byte( MODE2_REG, mode ); } /* * Public Functions -- Declared external in Config.h */ void InitializeLEDs(void) { char i; // BYTE dta; // First get the defaults. for (i=0; i<(char)sizeof(LEDInitData); i++) DevData[i] = LEDInitData[i]; // Then fill in the EEROM values into buffer for transmission to TL56119 register locations. // They are put into DevData[location + 1] to leave room at the front of the buffer for the IIC address. RedLevel = Get_ObEEROM_Byte(EM_RED_LEVEL); for (i = (RED_PWM_GROUP_START+1); i <= (RED_PWM_GROUP_END+1); i++) DevData[i] = RedLevel; GreenLevel = Get_ObEEROM_Byte(EM_GREEN_LEVEL); for (i = (GREEN_PWM_GROUP_START+1); i <= (GREEN_PWM_GROUP_END+1); i++) DevData[i] = GreenLevel; BlueLevel = Get_ObEEROM_Byte(EM_BLUE_LEVEL); for (i = (BLUE_PWM_GROUP_START+1); i <= (BLUE_PWM_GROUP_END+1); i++) DevData[i] = BlueLevel; WhiteLevel = Get_ObEEROM_Byte(EM_WHITE_LEVEL); for (i = (WHITE_PWM_GROUP_START+1); i <= (WHITE_PWM_GROUP_END+1); i++) DevData[i] = WhiteLevel; // Default Intensity. DevData[GRPPWM_REG+1] = Get_ObEEROM_Byte(EM_INTENSITY); // Given we have a 750 Ohm 0.5% resistor the IREG value is set to create 20mA through the LEDs DevData[IREF_REG+1] = Get_ObEEROM_Byte(EM_IREF); // Finally send list of register values to the TL device. Put_IIC_TL59116_Buf( MODE1_REG, sizeof(LEDInitData), DevData ); // Then reset the ERROR Flags. Put_IIC_TL59116_Byte( MODE2_REG, 0x80 ); // Reset Error Status Register. if (fFlash) { SetIntensity( Get_ObEEROM_Byte(EM_FLASH_PWM), Get_ObEEROM_Byte(EM_FLASH_FREQ), 0x20 ); } else { SetIntensity( Get_ObEEROM_Byte(EM_INTENSITY), 0, 0 ); } } Generally as CAN messages arrive with colour information the IIC display image is filled with the new data and then sent out to the device.
    /*
     *	UpdateLights --	Fills up buffer with global light intensity values and
     *					sends buffer out to TL59116.
     */
    void
    UpdateLights(void) {
    BYTE i;
    	DevData[0] = RED_PWM_GROUP_START;	// Address of first colour register in device.
    	// Now fill in the colour map.				
    	for (i=1; i<(BYTE)17; i++) { // From PWM0 to PWM15.
    		ClrWdt();
    		// Put into DevData 1..1
    		if (i<=(BYTE)4) 
    			DevData[i] = RedLevel;
    		else if (i<=(BYTE)8)
    			DevData[i] = GreenLevel;
    		else if (i<(BYTE)13)
    			DevData[i] = BlueLevel;
    		else 
    			DevData[i] = WhiteLevel;
    	}
    	if (fShimmer) { // Are we using the Flash Rate values for Shimmer?
    		DevData[17] = ShimmerIntensity;	// Use this PWM rate for shimmer.
    	}
    	else {
    		DevData[17] = Intensity;	
    	}
    	// Update device.
    	Put_IIC_TL59116_Buf( PWM0_REG, 18, DevData );
    }
    

    Or if the CAN message with just the intensity value arrives this is what is done.

    					  // Set brightness differently from stored level.
    					  case SET_INTENSITY : 	//			2		
    						if (TextZoneValid(senderID, CANMsgRxRec.data[2])) {
    							Intensity = CANMsgRxRec.data[1];
    							SetIntensity( Intensity, 0, 0 );
    							OPFlags.Byte = 0;		// Disable random intensity
    						}
    						break;
    

  • Thanks for the code Jason. It looks like I can recreate the issue by doing multiple AUTO-INCREMENT calls where I slowly decrease the PWM value? I'll see if I can recreate the flickering.
  • Jason hasn't posted his code yet. This was mine from the project in my original posting many years ago.
    John
  • Sorry about that John,

    Can you please confirm this statement:
    It looks like I can recreate the issue by doing multiple AUTO-INCREMENT calls where I slowly decrease the PWM value? I'll see if I can recreate the flickering.
  • I have a Delphi Windows application with sliders for each of the RGBW and I values. I get the flickering when I move the intensity slider. The app sends out messages to a Freescale 9S12 controller that has 5 CAN bus channels that are updated every 40mS. (25Hz).

    Moving the slider which changes the intensity value has no correlation with the flickering. Sometimes there are minimal flickers, other times lots. Run through 0 to 255 and back down and you will get flickering. At least with my code.
  • tlc59116_example.zip

    See attached a zip file for a CCS project to demonstrate the issue.

    On the PCB I have an MSP430F5510 with the TLC59116 connected with the I2C interface on USCI_B (pins 4.1 and 4.2) and the RESET pin connected to pin 4.6 (with an external 10k pullup resistor). All the address pins on the TLC59116 are pulled to ground. The value of REXT is 3.3k. I have 4 RGB LEDs connected on OUT0-OUT11. I have a 0.1u decoupling cap on VCC.

    There is an 8 MHz crystal on XT2 (pins 5.2 and 5.3) which is used to generate SMCLK, but you could modify the code to use something else. It's just for using Timer A2 to step the brightness up and down.

    The code sets the LEDs to an initial color and turns them on (controlled by individual PWM registers and GRPPWM register). It then continuously writes values to GRPPWM to step from 0 to 255, and back, indefinitely. I don't use AUTO-INCREMENT in this example.

    This clearly demonstrates the flickering to me -- it will happen at least once around every other cycle.

    Hope this helps and please keep us posted on any solutions.

    Thanks,

    Jason

  • I'll need a few more days to work on this because of the break. I should have an update around 7/7/16
  • Harry Kennedy1 said:
    I'll need a few more days to work on this because of the break. I should have an update around 7/7/16

    I looked over the code and data sheet again.  I use auto increment and always set the GRPPWM and GRPFREQ together when group dimming and GRPFREQ == 0.  The LEDOUT Registers are set so each LED is 0b11 allowing both Group Dimming and Group Flashing.  Bit 5 in MODE2 register is cleared for normal operation.

    The function call to set the lamp intensity

    void SetIntensity( BYTE inten, BYTE freq, BYTE mode );

    is initialized as

      SetIntensity( Get_ObEEROM_Byte(EM_INTENSITY), 0, 0 );

    Unless the device is supposed to power up as a flashing beacon in which case

      SetIntensity( Get_ObEEROM_Byte(EM_FLASH_PWM), Get_ObEEROM_Byte(EM_FLASH_FREQ), 0x20 );

    Notice here Bit5 is set to use GRPFREQ to flash. 

    This all works.

    But sending a decreasing intensity level is done like this:

           Intensity = CANMsgRxRec.data[1];
           SetIntensity( Intensity, 0, 0 );

    And I get the random flashes.

    I believe the group dimming works like this:

    A 97kHz internal 8 bit counter is compared against the GRPPWM register.  When it matches the LEDs are turned off.  When it reaches 255 it wraps around to 0 and the LEDs are turned on again.

    Normally that works fine.  But if the IIC message is updating the GRPPWM register at the same time that the compare is occurring the compare reads 255 rather than the value in the register because the register value is currently unknown.  Ie. While the register write is in progress a read returns 0xff.  But it does that only once. 

    Say the GRPPWM is 0x3F.  And the value 0x3E is being written.  When the counter reaches 0x3F the compare is against 0xFF because of the IIC write so the LEDs stay on.  At 0xFF they are still on since the compare to turn them off never occurred.  The Counter restarts at 0 and this time matches 0x3E (the new value) and shuts off the LEDs.

    Time on then is for 0xFF + 0x3E counts of the 97kHz PWM counter.  That's about 3mS. 

    To test this theory will require a logic analyzer or storage scope that is triggered on each write to the GRPPWM register and captures an LED output.  Code should probably just alternate between two GRPPWM values.  If the LED OUPTUT is stretched relative to the same point in the IIC write sequence we know it's the device.

    Perhaps reading a LED drive value and only updating the GRPPWM register when it's low?

  • Hello,

    I also experienced the same failure as your guys have.

    The LED shows random flash, when I decrease GRPPWM value continuously from 0xFF to 0x00.

    The flash only pops out in continuous decrements, never happend in increase.

    Our hardware design is to use TLC59116 to drive 16 LEDs and use a microcontroller to talk with TLC59116 over I2C.

    The configure register on TLC59116 is:

    MODE1 = 0x10

    MODE2 = 0x00

    LEDOUTx = 0xFF

    PWMx = 0xFF

    The microcontroller is changing GRPPWM register only in runtime. 

    The following log shows the register writing when the flash happened.

    We are using an I2C analyzer to check if there is any error on bus during the register change.

    But no error is observed.

    0:12.586.623 221.400 us 2 B Write Transaction 12 FF
    0:13.992.695 220.300 us 2 B Write Transaction 12 FE
    0:14.280.842 220.200 us 2 B Write Transaction 12 FD
    0:14.380.845 221.400 us 2 B Write Transaction 12 FC
    0:14.480.860 220.200 us 2 B Write Transaction 12 FB
    0:14.580.877 220.900 us 2 B Write Transaction 12 FA
    0:14.684.822 221.600 us 2 B Write Transaction 12 F9
    0:14.780.922 221.500 us 2 B Write Transaction 12 F8
    0:14.880.945 220.500 us 2 B Write Transaction 12 F7
    0:14.980.945 220.700 us 2 B Write Transaction 12 F6
    0:15.080.961 221.100 us 2 B Write Transaction 12 F5
    0:15.180.987 220.300 us 2 B Write Transaction 12 F4
    0:15.280.997 221.700 us 2 B Write Transaction 12 F3
    0:15.415.752 219.900 us 2 B Write Transaction 12 F2
    0:15.492.412 221.200 us 2 B Write Transaction 12 F1
    0:15.608.301 221.600 us 2 B Write Transaction 12 F0
    0:15.724.957 221.300 us 2 B Write Transaction 12 EF
    0:15.887.385 220.700 us 2 B Write Transaction 12 EE
    0:15.981.130 221.100 us 2 B Write Transaction 12 ED
    0:16.088.889 221.100 us 2 B Write Transaction 12 EC
    0:16.181.139 221.300 us 2 B Write Transaction 12 EB
    0:16.290.231 220.500 us 2 B Write Transaction 12 EA
    0:16.381.185 220.700 us 2 B Write Transaction 12 E9
    0:16.493.384 221.300 us 2 B Write Transaction 12 DF
    0:16.581.226 219.800 us 2 B Write Transaction 12 D5
    0:16.728.540 220.800 us 2 B Write Transaction 12 CB
    0:16.781.256 220.300 us 2 B Write Transaction 12 C1
    0:16.897.524 220.400 us 2 B Write Transaction 12 B7
    0:16.981.282 221.600 us 2 B Write Transaction 12 AD
    0:17.098.925 221.600 us 2 B Write Transaction 12 A3
    0:17.181.303 220.900 us 2 B Write Transaction 12 99
    0:17.300.423 221.100 us 2 B Write Transaction 12 8F
    0:17.384.091 220.800 us 2 B Write Transaction 12 85
    0:17.496.881 221.400 us 2 B Write Transaction 12 7B
    0:17.585.463 220.500 us 2 B Write Transaction 12 71
    0:17.712.326 220.300 us 2 B Write Transaction 12 67
    0:17.787.064 221.400 us 2 B Write Transaction 12 5D
    0:17.881.419 221.600 us 2 B Write Transaction 12 53
    0:17.988.219 221.200 us 2 B Write Transaction 12 49
    0:18.081.459 221.200 us 2 B Write Transaction 12 3F
    0:18.189.557 221.500 us 2 B Write Transaction 12 35
    0:18.281.480 221.800 us 2 B Write Transaction 12 2B
    0:18.392.472 220.100 us 2 B Write Transaction 12 21
    0:18.481.526 221.500 us 2 B Write Transaction 12 17
    0:18.594.270 221.600 us 2 B Write Transaction 12 0D
    0:18.681.549 220.300 us 2 B Write Transaction 12 03
    0:18.795.702 221.600 us 2 B Write Transaction 12 00

    The we probe one output from TLC59116, the wave shows there is flashing change in one or two cycles, the duty cycle of PWM is set to high.

    The flashing is quite annoying and we got several complain from customer.

    Hope we can sort it out what is wrong here.

    Wei

  • Hi Harry,

    Any update on this?

    Thanks again for your help!

    Jason
  • Hi Harry,

    Please let me know if you have an update. We'd really love some help from TI to develop a workaround, or at least an explanation of the defect. Otherwise we'll need to switch to a different part.

    Note that my code doesn't use AUTO-INCREMENT.

    Thanks,
    Jason
  • All,

    We haven't been able to find a root cause. Setting these values with a longer wait in between calls should help the situation.

  • Harry Kennedy1 said:

    We haven't been able to find a root cause. Setting these values with a longer wait in between calls should help the situation.

    I  take it there's no one left at TI that was involved in the design of that device?  That access to the design information isn't possible so there's no way to look at it and say "Oh Crap! There's the reason!"

    I can't see longer waits would make any difference other than make the random blinks occur less often.  That's like saying you can avoid making it do the random flashes by just not using that register. That isn't a solution. 

    It was our solution though.  For any of the 2010 Winter Olympic Ring Light shows we simply didn't use the global intensity register.  When I do seminars on that project (or forum postings) TI gets mentioned as the chip that had problems.

    And because the support has been so poor on this I haven't designed in a TI LED part since 2009.   I now have lots of surplus Ring Lights.  I'm repurposing them as garden and bollard lights.  For night path lighting the global intensity is really important for gradually bringing up intensity of a particular shade over a short periodi  but I'm not holding my breath on this. 

    Regards

    John Dammeyer