Reliabilty difrence between JW and 04/SM 12C672

Wessel · Guest

The Problem is that the development pic 12C672 JW works 100\% while the 12C672 04/SM has a 1.4\% to 6.2\% error. The error is when the PIC receives the string that triggers the process nothing happens no data is being sent out. I tested serveral 04/SM Pics and the result is the same on all.

There is three devices connected on the pic two devices is communicating at 9600 BAUD and the third is comunicating at 4800 Buad this device is continiusly suplying data. The trigger device is cominicating on 9600 Baud.

ANY IDEAS
or
SULUTIONS? 
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515169

Tomi · Guest

Do you use the PIC's internal 4MHz oscillator?
If so then keep in mind that the OSCCAL register handling strategy is different. When using the JW device you have to read out and save the oscillator calibration data because it is cleared under the UV lamp.
When using OTP version leave the calibration data untouched (it is factory pre-programmed).

:=The Problem is that the development pic 12C672 JW works 100\% while the 12C672 04/SM has a 1.4\% to 6.2\% error. The error is when the PIC receives the string that triggers the process nothing happens no data is being sent out. I tested serveral 04/SM Pics and the result is the same on all.
:=
:=There is three devices connected on the pic two devices is communicating at 9600 BAUD and the third is comunicating at 4800 Buad this device is continiusly suplying data. The trigger device is cominicating on 9600 Baud.
:=
:=ANY IDEAS
:=or
:=SULUTIONS? 
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515171

Wessel · Guest

Yes the internal oscillator is used and the oscal register is loaded.

The problem is with the OTP Device 12C672 04/SM.
I programmed one with the clk out(osc 2) enabled and the output frequency is within the 1MHz range.

:=Do you use the PIC's internal 4MHz oscillator?
:=If so then keep in mind that the OSCCAL register handling strategy is different. When using the JW device you have to read out and save the oscillator calibration data because it is cleared under the UV lamp.
:=When using OTP version leave the calibration data untouched (it is factory pre-programmed).
:=
:=:=The Problem is that the development pic 12C672 JW works 100\% while the 12C672 04/SM has a 1.4\% to 6.2\% error. The error is when the PIC receives the string that triggers the process nothing happens no data is being sent out. I tested serveral 04/SM Pics and the result is the same on all.
:=:=
:=:=There is three devices connected on the pic two devices is communicating at 9600 BAUD and the third is comunicating at 4800 Buad this device is continiusly suplying data. The trigger device is cominicating on 9600 Baud.
:=:=
:=:=ANY IDEAS
:=:=or
:=:=SULUTIONS? 
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515173

Wessel · Guest

Yes the internal oscillator is used and the oscal register is loaded.

The problem is with the OTP Device 12C672 04/SM.
I programmed one with the clk out(osc 2) enabled and the output frequency is within the 1MHz range. Theoretically if the program works without errors on the JW it should also do so in the 04/SM :( .

:=Do you use the PIC's internal 4MHz oscillator?
:=If so then keep in mind that the OSCCAL register handling strategy is different. When using the JW device you have to read out and save the oscillator calibration data because it is cleared under the UV lamp.
:=When using OTP version leave the calibration data untouched (it is factory pre-programmed).
:=
:=:=The Problem is that the development pic 12C672 JW works 100\% while the 12C672 04/SM has a 1.4\% to 6.2\% error. The error is when the PIC receives the string that triggers the process nothing happens no data is being sent out. I tested serveral 04/SM Pics and the result is the same on all.
:=:=
:=:=There is three devices connected on the pic two devices is communicating at 9600 BAUD and the third is comunicating at 4800 Buad this device is continiusly suplying data. The trigger device is cominicating on 9600 Baud.
:=:=
:=:=ANY IDEAS
:=:=or
:=:=SULUTIONS? 
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515174

Tomi · Guest

Accuracy? Keep in mind that you have to have max. 1.5\% error to get a reliable serial communication.

:=I programmed one with the clk out(osc 2) enabled and the output frequency is within the 1MHz range.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515175

Wessel · Guest

Do you mean that the frequancy should be within that error range:? The maximum error on the frequancy is less than 1.5\%

:=Accuracy? Keep in mind that you have to have max. 1.5\% error to get a reliable serial communication.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515177

Sherpa Doug · Guest

:=The Problem is that the development pic 12C672 JW works 100\% while the 12C672 04/SM has a 1.4\% to 6.2\% error. The error is when the PIC receives the string that triggers the process nothing happens no data is being sent out. I tested serveral 04/SM Pics and the result is the same on all.
:=
:=There is three devices connected on the pic two devices is communicating at 9600 BAUD and the third is comunicating at 4800 Buad this device is continiusly suplying data. The trigger device is cominicating on 9600 Baud.
:=
:=ANY IDEAS
:=or
:=SULUTIONS? 

I don't understand the problem. When you say 1.4 to 6.2\% error do you mean the baud rate is off by that much? Do you mean a calculated value is off by that much? Do you mean that often an incomming command is missed? Do you meant that often you fail to get any outgoing message? or is the outgoing message garbled?

I'd like to help if I understood the problem.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515178

Wessel · Guest

I mean out of 465 triggers 13 didn't respond. Basicly the pic didn't send out any information(outgoing message),no response would be correct. Please ask if there needs to be more clarifying to be done.

Thank you

:=I don't understand the problem. When you say 1.4 to 6.2\% error do you mean the baud rate is off by that much? Do you mean a calculated value is off by that much? Do you mean that often an incomming command is missed? Do you meant that often you fail to get any outgoing message? or is the outgoing message garbled?
:=
:=I'd like to help if I understood the problem.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515179

Sherpa Doug · Guest

Ah! the fog clears...
You checked the baud rate and it is within tollerance. Are you using a software or hardware UART? Also are you initializing your variables and input buffer. I know with the 16C5x chips the windowed parts tend to have RAM zeroed by ambient light. When you switch to a non-windowed part nasty initialization bugs can appear.

:=I mean out of 465 triggers 13 didn't respond. Basicly the pic didn't send out any information(outgoing message),no response would be correct. Please ask if there needs to be more clarifying to be done.
:=
:=Thank you
:=
:=:=I don't understand the problem. When you say 1.4 to 6.2\% error do you mean the baud rate is off by that much? Do you mean a calculated value is off by that much? Do you mean that often an incomming command is missed? Do you meant that often you fail to get any outgoing message? or is the outgoing message garbled?
:=:=
:=:=I'd like to help if I understood the problem.

___________________________
This message was ported from CCS's old forum
Original Post ID: 144515180

Wessel · Guest

A software UART the 12C672 doesn't have a hardware UART. The BAUD rate is within the tolerances. could these initialization bugs cause a problem where the PIC works well for minute or longer and the give a Problem :?

I think I should block the window and try the test again. and see if the problems appear on the UV PIC.

:=Ah! the fog clears...
:=You checked the baud rate and it is within tollerance. Are you using a software or hardware UART? Also are you initializing your variables and input buffer. I know with the 16C5x chips the windowed parts tend to have RAM zeroed by ambient light. When you switch to a non-windowed part nasty initialization bugs can appear.

___________________________
This message was ported from CCS's old forum
Original Post ID: 144515181

Sherpa Doug · Guest

:=A software UART the 12C672 doesn't have a hardware UART. The BAUD rate is within the tolerances. could these initialization bugs cause a problem where the PIC works well for minute or longer and the give a Problem :?

Might you have a circular comms input buffer that takes a while to fill and wrap around. The problem may only occur when the buffer wraps.

:=I think I should block the window and try the test again. and see if the problems appear on the UV PIC.
:=
:=:=Ah! the fog clears...
:=:=You checked the baud rate and it is within tollerance. Are you using a software or hardware UART? Also are you initializing your variables and input buffer. I know with the 16C5x chips the windowed parts tend to have RAM zeroed by ambient light. When you switch to a non-windowed part nasty initialization bugs can appear.
:=
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515183

Wessel · Guest

No A Linear Buffer is used.

:=Might you have a circular comms input buffer that takes a while to fill and wrap around. The problem may only occur when the buffer wraps.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515314