Intermittent working PICs

This code is sufficient for the UART check.
It has been fully tested and I have never seen it fail on this project.


read_azim:
Hserget hdr1 'remote Azimuth from 18F4520 PIC, it expects AxxxExxx in ASCII format'' the hserget flushes out any odd characters

If hdr1 <> "A" Then Goto clr_azim 'wait for 'A' sync character' if Hserget reads only a 'A' will it continue else it will loop back to read_azim and flush the uart buffer

For rx = 0 To 6 'get all 6 characters' Hserin will read in the remaining characters of the string
Hserin gpsrxd
uartrxd = uartrxd + gpsrxd
Next rx

If MidStr(uartrxd, 4, 1) <> "E" Then Goto clr_azim' a further verification of the string, testing for 'E' in the correct location
,
gpsazim = LeftStr(uartrxd, 3)
gpselev = RightStr(uartrxd, 3) '++++ for Elev
azimval = StrValW(gpsazim) 'convert ascii to numeric and
elevval = StrValW(gpselev) '++++

If azimval > 359 Then
Goto clr_azim 'invalid so await next azim input' another string verification checking the value is less then 360 degrees
Endif

Hi,

If it would help, I have some 20MHz XTLs I can add. If this is a good idea for a test, could you change the set-up to suit, please?

Camerart.

Eric ... and if the overrun error bit gets set ? you will never receive the 'A' . I have always found polling the RCREG problematical .

REGISTER 20-2: RCSTA: RECEIVE STATUS AND CONTROL REGISTER

bit 1 OERR: Overrun Error bit
1 = Overrun error (can be cleared by clearing bit, CREN)
0 = No overrun error

Has anyone ever used the overrun error bit? - there's seems little or no reason for it's use.

I always have it in my code...


If there is an overrun... It crashes the serial port!!

Nigel . Camerart's problem is that a PIC18F2431 , seems to be starting up OK as it flashes a led , but then appears to be , for want of a better word dead. the main purpose of the program is to take data from the serial port in the form of AxxxExxx ( ascii) and perform a control of a motor , with feedback. If the AxxxExxx was received then the led flashes again ....It don't. OK a Debug would find it , but this is not available , so we are left with intelligent guesses as to where the pic is going. and what could possibly stop the UART receiver. OERR can do that... also pic instruction cycle is only 2 MIPS , UART RCREG reading is in a loop with delays and comms TX that could possibly be longer that it takes for a byte to arrive 1 msec @ 9600. to add to the mystery he has one pic with same code , works fine.....

Hi,
You should be aware that 'Camerart' has made his own quadrature encoder disc which is geared up by a factor of 100, between the disc and the scanning head unit.

I stripped a professional grade encoder from one of my laser double bearing units so that I could test out the Oshonsoft positioning control program, it works fine in a hardware test jig in either clockwise or anti-clockwise drive direction and when passing thru 000 degree's. [the program calculates the shortest drive direction]

I tested both the Azimuth and Elevation positioning program functions they work fine.

With regard to the AaaaEeee string from the 18F4520 to the 18F2431's [ azim and elev] , tests were done using various corrupted strings, the UART subr has never locked up.

One problem the OP/TS is having is that the Oshonsoft IDE does not support the Quadrature model of the 18F2431, ie: POSCNT/CAPTURE or INDEX features, so he cannot simulate the program, thats why I built the test jig.

Another problem was that the 18F2431 would not program without adding extra links to the prommer socket.

My advice to the OP/TS would be to write a simple test program for the 18F2431, eg: say using a timer inter interrupt to drive one LED and Toggle another LED outside the ISR, lets see if the PIC's or Prommer are defective.

Eric

Hi,

As I'm not 'up' in programming, I can only follow your suggestions, while trying tests at my level.

I think I have eliminated the Terminal/FTDI problem as now the 184520 can send the required AxxxExxx needed by the 18F2431,s.
I have a program that works on all PICs, that spins the motors via 4x FET Hbridge, that stops, waits and reverses, constantly.
I'm guessing that as there is a toggle LED immediately after the 1st (I think) external action, that never flashes, on all but one PIC, that it's more to do with the clock, and it isn't the opto encoders???

The problem started, while using a PicKit2, so I bought a PK3 and made a ZIF circuit that allows external voltage, and LVP, which copies the 'programming socket' that Eric mentions.. Since using all of this, all of the PICs now program in the PK2 as before.

If I try adding a 20MHz XTL, can I simply comment out OSCCON as a test?

Camerart.

C Your 20Mhz may upset other timings. External osc needs config and init...

If you want to try an external xtal, use the Configuration option in the IDE menu.

Example for the 18F4520 attached. The top CONFIG group is the one you want , delete the lower group.

You MUST recompile the Basic program.

ericgibbs said:

If you want to try an external xtal, use the Configuration option in the IDE menu.

Example for the 18F4520 attached. The top CONFIG group is the one you want , delete the lower group.

You MUST recompile the Basic program.

Click to expand...

Hi Eric,

Thanks I'll give it a go.

EDIT: When I compiled the PIC, the config group had changed. Your config group is for 18F4520. Is this the same for 18F2431, that I'm working on? Also your image show HS not XT, is this correct?

EDIT: I re-read the 18F2431 and now see HS.
EDIT: I tried your config group on an 18F4520 and it looks ok, I now see that it is a suggestion, to only change HS in the 18F2431 config group. Easily confused

C.

Hi,

Would someone be good enough to help me set up for 20MHz XTL please.

I've been reading the PDF, about OSCCON--HSPL etc, I've been trying to set them, but soon get baffled by much of it To me it looks like OSCCON = %10000000 looks correct.

Here's the program:

Camerart.

Use OSCCON=0
Define CLOCK_FREQUENCY = 20

ericgibbs said:

Use OSCCON=0
Define CLOCK_FREQUENCY = 20

Click to expand...

Ok, thank Eric.

C , Been mulling over your problem , think possibly there is more than one bug.. so here goes.
Bug 1 , the TX to RX link.... on power up reset both the 4520TX - 2431 RX pins are inputs... Question ... which PIC initializes its UART first ? if 2431 initializes first ( now faster at 20Mhz / 5 MIPS ) then UART RX pin is effectively a floating input = Overrrrrrrrun error !
(try a 4k7 pull up).
Bug 2 , If you have programmed PIC with LVP enabled then for normal operations pin 26 PGM has to be grounded NOT open,. This was discussed previously , just wanted to make it clear.
Bug 2.1 What's happening with other 2431 unconnected pins ?

G.

hi C,
Attached is a Oshonsoft Sim program for the Quad PWM simulation.
It auto cycles thru a list of 8 programmed Azim values and the POSCNT auto Inc/Dec's as required to sim PWM drive in the CW or CCW direction towards a Match.
You should find this useful when trying the Band values for the 'hunting' problem.
NOTE: I have made the values 0 thru 359 so that you do not have to wait for ages while running the program, try it.

Also I have extensively run a test program for the 18F2431 UART RXD function, the OERR and FERR are NOT a problem

Eric

granddad said:

C , Been mulling over your problem , think possibly there is more than one bug.. so here goes.
Bug 1 , the TX to RX link.... on power up reset both the 4520TX - 2431 RX pins are inputs... Question ... which PIC initializes its UART first ? if 2431 initializes first ( now faster at 20Mhz / 5 MIPS ) then UART RX pin is effectively a floating input = Overrrrrrrrun error !
(try a 4k7 pull up).
Bug 2 , If you have programmed PIC with LVP enabled then for normal operations pin 26 PGM has to be grounded NOT open,. This was discussed previously , just wanted to make it clear.
Bug 2.1 What's happening with other 2431 unconnected pins ?

G.

Click to expand...

Bug1, As the problem is when the 18F4520 is connected, also from a Terminal, I've put this down the list.
Bug2, I've tried all possible programming combinations I think.
Bug3, Any legs not used are floating free, so this goes up the list of things to try. (This was mentioned earlier, not forgotten)

Camerart.

ericgibbs said:

hi C,
Attached is a Oshonsoft Sim program for the Quad PWM simulation.
It auto cycles thru a list of 8 programmed Azim values and the POSCNT auto Inc/Dec's as required to sim PWM drive in the CW or CCW direction towards a Match.
You should find this useful when trying the Band values for the 'hunting' problem.
NOTE: I have made the values 0 thru 359 so that you do not have to wait for ages while running the program, try it.

Also I have extensively run a test program for the 18F2431 UART RXD function, the OERR and FERR are NOT a problem

Eric

Click to expand...

Thanks Eric,

This work ok in SIM.

I'm not sure if you wanted me to try it in the Circuit, but with no thought, I compiled it and this is what appears in the TX terminal:

I tried 2x PICs and they both did the same.

I'll

C.

hi,
It was for simulation only.
Would you like me to write a short program for testing 18F2431's.??

E

ericgibbs said:

hi,
It was for simulation only.
Would you like me to write a short program for testing 18F2431's.??

E

Click to expand...

Hi Eric,

I know you have tested the 18F2431 with Internal osc, and proved it works. As a test I added a 20 MHz XTL, and the initial LED flash worked, but not the toggle LED.

While trying to get it to 'fire up' I noticed to my embarrassment, that there are Button switches on the same tracks. I had to cut the track to get it to work. I'm not sure if this affects all the Internal Osc readings? The XTL wave on the oscilloscope wasn't as strong as the one I added earlier to the 18F4520.

Let me try again over the weekend, then I may ask you to write a test program. Nice offer.

Camerart.