AVR and Freescale MC14489BP 7 segment Driver, help please!!!

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You guys have never let me down before, so here goes. I have been having problems with having the AVR drive the MC14489 7 segment LED driver IC.

The com protocol is SPI.

Here is my problem. I often get very slow refresh rates on the LEDs, the refresh rate sometimes is very good, sometimes very bad, and sometimes in the middle.

I have several Display modules that I made; PCB, LED, MC14489, etc... On some modules, everything is fine, however out of the blue they will start to show a poor refresh rate and it will stay that way. On modules that usually have the refresh rate problem, it often fixes itself and stays that way.

I have been spending so much time trying to trouble shoot this problem and I am ready to give up. I need help badly.

Here is my code to test the displays

SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1);

//write config byte
LED_Enable=0;
SPSR=0;
SPDR = 1;
while(!(SPSR & (1<<SPIF)));
LED_Enable=1;

//Have LED show "1010"
LED_Enable=0;
SPSR=0;
SPDR = 1;
while(!(SPSR & (1<<SPIF)));

SPSR=0;
SPDR = 1;
while(!(SPSR & (1<<SPIF)));

SPSR=0;
SPDR = 1;
while(!(SPSR & (1<<SPIF)));

LED_Enable=1;

Regards,

Alan To

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toalan wrote:
I have several Display modules that I made; PCB, LED, MC14489, etc... On some modules, everything is fine, however out of the blue they will start to show a poor refresh rate and it will stay that way. On modules that usually have the refresh rate problem, it often fixes itself and stays that way.

So it is the blue LEDs that have this problem ? (could not resist :twisted:)

Is Your refresh interrupt driven? If so, then the possible causes are a tad smaller in numbers.
- check that the MCU is running on the designed frequency (no internal RC osc).
- check that the timer that drives the scanning is correctly configured
- maybe a variable problem caused by forgetting to have the "volatile" attribute on variables that are manipulated by the ISR

If You scanning is not interrupt driven then my first quess would be that some subroutine is taking a lot longer than designed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The test code is not interrupt driven, it is all poll driven. I just hooked up my LA and the SPI packets looked good.

I checked the timing and everything looks well above the min and max times on the mc14489bp datasheet

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never used the MC14489, but I have used the MAX7219. In practice, a MAX7219 gets out of sync occasionally and puts itself in the power-on state. Unfortunately this is full-brightness, full segments and exceeds my long term average power supply current. My solution was to just periodically re-initialise the chip and update the display mode and registers.

I presume that you are using Fig 9. of the MC14489 data sheet. I suggest that you do a similar kludge, but I would be interested in how extraneous clock pulses intrude to put the chip out of sync.

A small low-pass filter may be helpful on the clock line with about 500ns time constant.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David,

I do suspect there is a sync problem, that is the only thing I can think of.

I will try putting a rc filter on the clock.

Thanks,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

I made a breakthrough. I put a 100uf Cap on the 5v line of the mc14489 and this was what was causing the problem.

I think the initial problem is caused by sending SPI data before the Cap gets fully charged to 5v. This puts the mc14489 into a half broken state and stays in that state. Even when I reset the display by writing to the config register, it does not work to get it out of the funk.

The solution is to fully power down VDD to reset the mc14489. Because of the 100uf cap, it would take a while for VDD to to fall to Vss. This was why sometimes when I disconnect and reconnect the display, it would work, and sometimes it would not work.

Regards,

Alan To

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That does not make any sense at all. If your displays are taking an average total current of 50mA to 500mA, a 100uF capacitor is going to have a time constant of between 1ms and 10ms.

If all displays are off, and you only have CMOS loads then the time constant could be between 100ms and 1s. So I can see that the chip may not get an effective power-on reset.

You should be able to reset the chip in software. And this would be wise in your initialisation anyway.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always did a software rest but that had no effect.

I am not going to rationalize why it is, I am just happy to able to manage the problem.

After the display is left unpowered the voltage on the 100uf Cap falls to about 0.6v and slowly drops to 0v. Apparently with 0.6v the mc14489 is not fully off and still has bad memories of the past.

Once the mc14489 exhibits the slow refresh rate, the only way to fix it is to fully power down the mc14489. Sending a software reset via the config register does not fix the problem.