i have a problem TPIC6A595DW &16F877A

[okmn]

i have a problem with TPIC6A595DW;

the outputs are self-active! sometimes of TPIC6A595DW although I did not send data to it.
some LEDs light up randomly (like 0.5 seconds) and then turn off immediately.

5 LEDs connected(power led 12v) so that the outputs are active at low "0" )

Code Select Expand

Device = 16F877A
Xtal = 20
Config FOSC_HS, WDTE_OFF, PWRTE_OFF, BOREN_OFF, LVP_OFF, CPD_OFF, WRT_OFF, DEBUG_OFF, CP_OFF

Symbol S_DATA = PORTD.4
Symbol S_RCK = PORTD.5
Symbol S_CLK = PORTD.6
Dim TPIC_IC5 As Byte
Dim TPIC_IC6 As Byte
'
'
'
TPIC_IC5 = 0
TPIC_IC6 = 0
GoSub TPIC_SUR
TPIC_IC5 = %00110000
'
'
'
If ''''''''Then TPIC_IC5 = %00000001
If ''''''''Then TPIC_IC5 = %00000010
If ''''''''Then TPIC_IC5 = %00000100
If'''''''''Then TPIC_IC5 = %00001000

TPIC_SUR:
If '''''''Then TPIC_IC6 = 0 
S_RCK=0
SHOut S_DATA,S_CLK,MsbFirst,[TPIC_IC6,TPIC_IC5]
S_RCK = 1
DelayUS 1
S_RCK = 0
Return


do i have some wrong to drive/control to TPIC6A595DW (blue colored code lines )

TPIC_SUR:
If '''''''Then TPIC_IC6 = 0 
S_RCK=0
SHOut S_DATA,S_CLK,MsbFirst,[TPIC_IC6,TPIC_IC5]
S_RCK = 1
DelayUS 1
S_RCK = 0
Return

can you share your advice or some sample codes!!

thank you in advance

[See_Mos]

How do you have SRCLR and G connected

Try SRCLR to 5v and G to 0V

[okmn]

pardon,
i forgot it to write

SCLR connected to the 5v direct
G connected to the gnd.

[See_Mos]

How many TPIC6A595DW do you have connected

Is SEROUT on one connected to SERIN on another?

[trastikata]

What are the If conditions? Did you check with a scope if the "random" flashes are not due to serial data send after something unexpected triggered the "If" statement?

[okmn]

there are 2 TPIC and they connected cascading tpic1 serout to tpic2 serin

"if condition" for To detect the incoming data ...from uart/pc tx   

"if the incoming data is $xx $xx $xx $xx $xx... turn on led1"

i checked with scope and no any data ..

a complete nonsense ,, it works for 1 hour without any problem, then suddenly it gives 1 LED or 2 or 3 LEDs instant light.

lgnd and pgnd are directly connected to each other.

[RGV250]

Hi,
Just a suggestion but do the devices need to be constantly written to or once data is written they stay static until new data is written.
If they are static would it be an idea to disconnect the data connections and leave it. If it changes then it is not the code.

Bob

[trastikata]

i checked with scope and no any data ..

If I understand correctly there is no serial transfer between the MCU and TPIC when the random flashes occur, otherwise said it is not because of register shift?

In this case it is a hardware issue, and not a code (program) problem.

[okmn]

If there is no other way to use it with tpıc serial communication, it means the use of "shout" in the code I wrote is correct.
mee too ,i am thinking tpic has problem

I'll change TPIC tomorrow.

[top204]

I know it sound obvious, but sometimes we all forget the simpler things, but make sure none of the pins are floating and make sure the pins not used are being pulled high or low.

Also make sure your pins are made outputs, because I noticed you are using them such as: S_RCK = 1. For testing, it is always recommended to use the High and Low commands so you know they are being made outputs, then go through the code optimising with PinSet and PinClear once the code works, knowing that the pins are set as outputs earlier in the code.

[See_Mos]

TOP204 is right.  I now try to start by clearing the PORT registers and any TRIS registers that are not needed as input.

Your SHOUT code works OK if the PIC pins are set to output be clearing the TRIS registers

Try a simpler code to test the TPIC. Something like

TRISD = 0
TPIC_IC5 = $0F : TPIC_IC6 = $F0
DelayMS 250
SHOut S_DATA,S_CLK,MsbFirst,[TPIC_IC6,TPIC_IC5]
S_RCK = 1
DelayUS 1
S_RCK = 0
While 1 = 1 : Wend

[okmn]

I think I'm getting old!

i could not find in latest pdf these commands PinSet  PinClear  but have "SetPin" and "ClearPin" 
but there are other commands that I did not look very carefully at the last "pdf" because I think they do the same job ... I need to understand what the difference is between them....pinmode ,getpin ,input , output ,clear, clear bit ,

to be honest i usually did not use "high" and "low" commands i preferred generally 1 or 0
i will care to use "high" and "low" for next times (and i will check with scope what is different then others to best understandt)
At first glance it seemed to me that they all do the same job

[okmn]

TOP204 is right.  I now try to start by clearing the PORT registers and any TRIS registers that are not needed as input.

Your SHOUT code works OK if the PIC pins are set to output be clearing the TRIS registers

Try a simpler code to test the TPIC. Something like

TRISD = 0
TPIC_IC5 = $0F : TPIC_IC6 = $F0
DelayMS 250
SHOut S_DATA,S_CLK,MsbFirst,[TPIC_IC6,TPIC_IC5]
S_RCK = 1
DelayUS 1
S_RCK = 0
While 1 = 1 : Wend

offiacly i added major needs begin of the my code but i did not put here..

i was worry about shout commands usign that i used correct or wrong

you can see the major commands of my codes begin what ..

Code Select Expand

Device = 16F877

Config FOSC_HS, WDTE_OFF, PWRTE_OFF, BOREN_OFF, LVP_OFF, CPD_OFF, WRT_OFF, DEBUG_OFF, CP_OFF

;**** End of Fuse Configurator Settings ****
;-------------------------------------------------------------------------------
Declare Xtal = 20
ADCON0.0 = 0
ADCON1 = 07 
All_Digital  true
'**********************************************************************
'PORT INPUT OUTPUT TRIS
'**********************************************************************
TRISA = 0
PORTA = 63
TRISB = 0
PORTB = 255
OPTION_REG.7 = 0
TRISC = %10000000

PORTC = 127
TRISD = %00001010
PORTD = 245
TRISE = 0
TRISE.4=0
PORTE = 7
PORTE.4=0
'**********************************************************************
Declare HPWM1_Pin PORTC.2 ' Select HPWM port and bit for PWM1 module (ch 1)
Declare HPWM2_Pin PORTC.1 ' Select HPWM port and bit for PWM 2 module (ch 2)
 '**********************************************************************
'BAUDRATE 19200  20MHZ
'**********************************************************************
    Declare Hserial_RCSTA=$90
    Declare Hserial_TXSTA=$24
    Declare Hserial_SPBRG=64 ' 19200 Bauds
    Declare Hserial_Clear=On
''**********************************************************************
''BAUDRATE 115200
''**********************************************************************
';Calculated Baudrate = 113636 @ Xtal 20MHz, Error = -1,36%
'    Declare Hserial_RCSTA = 144 ; Enable continuous receive
'    Declare Hserial_TXSTA = 36  ; Enable transmit, BRGH = 1
'    Declare Hserial_SPBRG = 10  ; Baud Rate Generator Value
'    Declare Hserial_Clear = On  ; Clear overflow automatically
'**********************************************************************
'**********************************************************************
'INTCON: INTERRUPT CONTROL REGISTER
'**********************************************************************
Symbol GIE    = INTCON.7 
Symbol PEIE  = INTCON.6 
Symbol TMR0IE = INTCON.5 
Symbol INTE  = INTCON.4 
Symbol IOCIE  = INTCON.3 
Symbol TMR0IF = INTCON.2 
Symbol INTF  = INTCON.1 
Symbol IOCIF  = INTCON.0 
Symbol RCIE = PIE1.5     
Symbol RCIF = PIR1.5     
'Symbol sspen = SSPCON.5
'**********************************************************************
 RCIE = 1  'USART Recive Interrupt ENABLE
 'sspen = 0
 SSPCON = 0
 SSPCON2 = 0
 TMR0 = 12
'**********************************************************************
INTCON = $E0'11100000 $F0'$B0'$A0
'ADCON1 = 7
OPTION_REG = $07'00000111 $06  1:256
'**********************************************************************
what i remembered! ,i would ask a ouestion about porte.4 of 877a ?
PORTE.4=0

i know 877A does not has porte.4  but a day i wrote it with unwant  when i am writing  some ports status that day
and i saw the compiler did not warning about this wrong command lines
is it normal or is it a anomaly?

[top204]

The compiler sees that the device has a PORTE, but it cannot count the amount of pins (bits) that a port has in use. Because the Port is 8-bits in length, the compiler will allow all bits of the SFR (Special Function Register) to be referenced. It is up to the user to make sure that an SFR has the relevant bit in operation.

Some devices have a single bit of PORTE used when the MCLR pin is disabled, but as far as the compiler sees in its data files, the device has an 8-bit SFR named PORTE. The same with PORTA, and GPIO on the smaller devices. All of them are 8-bit SFRs, but only some of the bits are used within it, just like some other SFRs within a device.

If a user was to reference bit-8 of the SFR, the compiler would give an error because there is no bit-8 to an 8-bit variable, which is what an SFR actually is, but a variable with an internal meaning to the device itself.

If I remember correctly, the higher bits of PORTE or TRISE on a lot of the older devices actually manipulate peripherals within the device.

[See_Mos]

I use 0 and 1 in most of my code as well.

I do not have a DTPIC but I just tested your setup code and SHOUT code on my 16F877 hardware and I am getting the correct output at the PORT pins.

I set TPIC_IC5 and TPIC_IC6 to $AA (%10101010) to make it easier to see on the oscilloscope

[okmn]

The problem was fixed when I changed the tpic ..
but this is the second time it happened to me with these famous tpics ...

Of course, I left the possibility that the problem was with the integrated itself (because I bought it new, so it has never been used)
For this reason, I did not hesitate to ask the question of whether there is a problem with the code I wrote.

but i think tpic has an anomaly !!!

[See_Mos]

The TPIC is very old device.  You could look at MIC5821.  It does not have protection diodes but they are not needed for driving LED's

[okmn]

thank you to your advice it looks better then tpic6a595 for voltage and current values 80v and 500mA
but i think will not choose to use a "shift register" chip for port expander

It seems to me more stable and reliable(for now) to choose one of the new series "pic mcu", which has a lot of peripherals like 18F47K42 or 18F47Q43/53/83/84

I'm looking forward to the new compiler and its board with the new pdf.

The 877A has become a veteran now (carried us for many years).