Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Intermittent working PICs

Status
Not open for further replies.
hi C,
Using that working 18F2431 test program that ran OK on one 18F2431, I tried 3 other 18F2431's,
1 would not receive at all, only transmit, the other 2 had corrupt received data.
All programmed on the PICKIT3 , I will try programming with the PICStart+, and see if the results are the same.

E

UPDATE:
Reprogrammed all 4 18F2431's with PICStart+ using the same program.
2 now work OK.
2 are showing RXD corruption.!

C,
Methinks these 18F2431 should be reported to Microchip, see what they say.
 

Attachments

  • test1.txt
    635 bytes · Views: 265
Last edited:
Hi E,

I've been programming 2 or 3 PICs with the latest program, and they are mostly working, with the occasional glitch, which could be my typo. (I hope self driving cars aren't using them;))

If you recall, this problem started after I edited a program outside of Oshonsoft, then when I re-opened it on Oshonsoft, the trouble started, and it showed gobbledegook, until I bought a PicKit3 and made the new programming circuit for it. Is there any possibility that Oshonsoft is programming typos, something like, spacings or page format? or doesn't it work like that?

EDIT: I'm glad you can verify, faults at your end Eric.

EDIT I've contacted Microchip.

C.
 
Last edited:
hi C,
I have dropped the String type reading of the RXD and I have decided to use the Byte proven method we used on the 18F4520 for Neo/GPS reading and the same error trapping.

Then converting the 8 read bytes to characters after capturing the 8 bytes after the Hserin, would you believe all 4, 18F2431' are now working OK!!
These results suggests that something is not as we expect in the Oshonsoft string functions.???
As you recall we had problems with Hserout sometime ago, dropping off the last character in a String when the String did not end with Crlf [ this was reported to Vlad]

I used my PICStart+ as the prommer, I will now try programming with the PICKIT3 as see what I get.

Update:
Re-programmed using PICKIT3, the suspect PIC's from yesterday, they work OK.!

Please try your prommer on the program, let me know.

E
 

Attachments

  • Test2431_V12.txt
    5.8 KB · Views: 288
hi C,
I have dropped the String type reading of the RXD and I have decided to use the Byte proven method we used on the 18F4520 for Neo/GPS reading and the same error trapping.

Then converting the 8 read bytes to characters after capturing the 8 bytes after the Hserin, would you believe all 4, 18F2431' are now working OK!!

As you recall we had problems with Hserout sometime ago, dropping off the last character in a String when the String did not end with Crlf [ this was reported to Vlad]

I used my PICStart+ as the prommer, I will now try programming with the PICKIT3 as see what I get.

Update:
Re-programmed using PICKIT3, the suspect PIC's from yesterday, they work OK.!

Please try your prommer on the program, let me know.

E

Hi E,

Here's the LOG file from the test 1PIC:

Ignore the first part, I typed A123 which would take time.

UPDATE: 5x PICs OK. PicKit 2 used.

C.
 

Attachments

  • 140415.txt
    14.4 KB · Views: 273
Last edited:
hi,
Its curious why some of the PIC's could be affected by the use of Strings in that subr.??
I had tried adding all the usual FERR, OERR, CREN tests in the old string program to no avail.

However we seem to have a working solution.
So what is your next step in the project.?
E
 
hi,
Its curious why some of the PIC's could be affected by the use of Strings in that subr.??
I had tried adding all the usual FERR, OERR, CREN tests in the old string program to no avail.

However we seem to have a working solution.
So what is your next step in the project.?
E

Hi E,

Next thing! Get rid of my headache:) then:

I'll test the latest program a bit more. I'm away from it at the moment, but did you say there is no PWM yet? Once we're happy with this AZ program, we need a similar EL one, I'm not sure quite what stage that is, I suppose it needs this treatment.

Now I can send NMEA messages, I can connect it all, and test the whole system.

I tried XTLs in case the problem was from the clock, and found the initial LED 1sec ON/OFF wasn't smooth, and kind of un-dimmed before the ON 1sec. Strange! I thought I had seen this kind of behaviour before out of the corner of my eye, but was never sure.

C.
 
I'll test the latest program a bit more. I'm away from it at the moment, but did you say there is no PWM yet? Once we're happy with this AZ program, we need a similar EL one, I'm not sure quite what stage that is, I suppose it needs this treatment.

C,
You can use the same program for the Elev as the Azim for capturing the ElevVal, the Elev angle is already parsed from the A123E123 string.
Change the Limits
eg: instead of testing 180.0 deg for Azim to 'drive the shortest direction' use 000 Poscnt as the lowest Downward head tilt as -40 deg and the Upward tilt as +90 deg
[you do some Maths , so actual 000 Poscnt = -400 deg , 1300 = 900 deg]

also change the CAP3BUL/H pre-load from 3599 to 40+90 ie: 1300
The Azim compares should be Elev compares

I'll test the latest program a bit more. I'm away from it at the moment, but did you say there is no PWM yet?

I have built the 18F2431 circuit and will now add my 900 counts/rev encoder, so I have to change the limits to 18000 and 35999 for my further tests.
It will include the PWM drive signals, using Red/Blue LED's as CW or CCW indication for my testing ONLY, will post when ready.

[ Trying to get some bedding plants into the garden while its fine weather ]:joyful:

Do you follow that OK.?

E
 
E,

I'll give it all a go, and let you know if I get into difficulty. Thanks.

[Bought veg seeds and a rose for the watering can, hope to get some in tomorrow.]

C.

C,
You can use the same program for the Elev as the Azim for capturing the ElevVal, the Elev angle is already parsed from the A123E123 string.
Change the Limits
eg: instead of testing 180.0 deg for Azim to 'drive the shortest direction' use 000 Poscnt as the lowest Downward head tilt as -40 deg and the Upward tilt as +90 deg
[you do some Maths , so actual 000 Poscnt = -400 deg , 1300 = 900 deg]

also change the CAP3BUL/H pre-load from 3599 to 40+90 ie: 1300
The Azim compares should be Elev compares



I have built the 18F2431 circuit and will now add my 900 counts/rev encoder, so I have to change the limits to 18000 and 35999 for my further tests.
It will include the PWM drive signals, using Red/Blue LED's as CW or CCW indication for my testing ONLY, will post when ready.

[ Trying to get some bedding plants into the garden while its fine weather ]:joyful:

Do you follow that OK.?

E
 
hi,
Your STRVN program is showing a POSCNT reset when an INDEX is detected, I thought that you had removed the microswitch and intended to use POSCNT reset on MATCH.??
Can you confirm, as I have been trying my encoder in the program and I see you have the QEICON set for an INDEX detect.?

E
 
hi,
Your STRVN program is showing a POSCNT reset when an INDEX is detected, I thought that you had removed the microswitch and intended to use POSCNT reset on MATCH.??
Can you confirm, as I have been trying my encoder in the program and I see you have the QEICON set for an INDEX detect.?

E

Hi All, thanks for all of your help.

Hi Eric,

From memory, we decided to set both AZ and EL POSCNTs after moving the tracker, to the initialisation point (using a compass and level), by using buttons that I added for L/R U/D, then pushing INDEX buttons, to set zeros.

It appears that you have solved the STALLING problem. Once you are satisfied, perhaps you could finalise this thread please.

Back to the TRACKER thread.

C
 
Last edited:
Hi,
Normally the INDEX reset is used to reset the POSCNT to 000, when an INDEX pulse occurs at 000 deg and is generated by a 'MARK' on the encoder disc.
Your encoder disc gives only 9 pulses/rev and is geared up by a factor of 100 to give 900 quads/rev, also your encoder does not have an Index pulse/mark.

The 18F2431 uses both edges of the QEA and QEB pulses to give 3600 counts/rev

The idea was to have the program detect a POSCNT/CAP2CNT match and use the internal 18F2431 Interrupt to reset at a 0000 and 3599 POSCNT counts, because you do not have an Index pulse on the encoder disc.

The Manual reset button we discussed used for initialising the counters at power up, is to point the scanning head North and Level, then press the button, this would clear the POSCNT and preload the CAP2BUF countr with 3599. [also initialises the Elevation]

Its important that you make a decision which method you plan to use.

E

BTW: this is your Thread so you should decide to finalise it.;)
 
Hola camerart

Wading through the whole thread is not easy because albeit I have used the 18F4431 intensively in the past, it has been only in Assembly using a Picstart Plus.

Could you make a brief recap of the problem and its solution?

Gracias for that.
 
Hola camerart

Wading through the whole thread is not easy because albeit I have used the 18F4431 intensively in the past, it has been only in Assembly using a Picstart Plus.

Could you make a brief recap of the problem and its solution?

Gracias for that.

Hola A,

The problem could be a combination of: Oshonsoft doesn't support the 18F2431 QUADRATURE and PWM internal modules properly and possibly my inability to set all of the BITS correctly from the data sheet. The problem appears to be the RX input.

I also use the AAC forum and between the two forums have learnt a lot, thanks to very patient and helpful members. In the AAC forum, I'm working on a later suggestion where the RX is input in a different way, I'll let you know it works, if you let me know that you're working with the 18F2431 PIC.

Adios, C.
 
I used it for many many varied projects probably not strictly "specific" for that PIC.
Thanks.
 
Hi,

It was thought that the intermittent running of the 182431 PIC was due to programming, but it appears not to be so.

In the problem program + 18F2431, there is a 'wait for input at the RX PIN' I've been testing a variation of how it is input from EG, and it has worked every time so far, on all PICs. I need to study it to actually see how it works, but it seems to be the reason for stalling, and looking dead.

C.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top