Hi All,
I've been using the Synwrite IDE for a few years now without any major hassles. My timer system for Control Line model planes has been working very well. I have my pc boards populated here in South Africa by the same reputable firm that I've been working with for many years. With my last batch of boards I seem to be getting problems with just a few boards. I have a simple program for setting the motor rpm up or down that has worked since 2009. Now I have a few boards that simply will not allow me to set this rpm. I thought that there could be some I/O errors on the board for the 3 pushbuttons that I use so I checked the boards for continuity and all was o.k. I then wrote a short program to check the buttons. I have an LED on the board so I just used that as an indicator. All button circuits are good. Then I imported an old file that was compiled on the old version of GCB before Synwrite came out. The old program runs just fine. This is weird because the latest files work perfectly on most of the boards, Any idea's as to why this is happening? I would really appreciate any help. Thanks very much.
Regards,
Keith R
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had this problem myself, and it can very frustrating. Could be timing issues, GCB system variable, a .dat file issue, or? Sketchy buttons? And, check for solder bridges always on the hardware side.
What version of GCB that works? What version of GCB that gives the problems? Supply the device used and cutdown version of program that shows the problem.
Debug methods I use.
1. An output of the variables in the suspected code to a terminal.
2. Use an led to see if code processes conditional logic, and jumps to subs or interrupts properly .
3. Interrogation of the assembly output
P.S. Also swap good board mcu over to bad board to see if the 16f684 is duff?
Last edit: kent_twt4 2017-12-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Kent,
Thanks as always for the quick reply. The parts are all smd so I can't just change the chip unfortunately. I also wanted to watch the signals on my scope but it has blown the HT circuit so hopefully I can fix it shortly and then I'll report back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have now found a small bug in my code (I guess that there are many more!) that somehow effects this particular chip. It's still a mystery to me why this has not been a problem for many years with a load of pc boards. I began to think that it is a timing issue and as I said, this suspect board works with my older software. I thought that it could be a compiler issue so I went back to my old laptop which has GCB 0.9 10/2/2007 on it. I re-compiled the older versions of my program and it worked fine, so I used this to compile one of my latest versions. No joy! I then compiled the old software with the latest GCB and Synwrite and this too worked fines, so I knew that it was not a compiler issue.
After checking the differences in my old and newer software, I only found one section that effects this suspect pc board. My timer system for control line models sets the rpm to the ESC (Electronic Speed Controller) for brushless dc motors. The user can set the rpm up or down one click at a time with 2 pushbutton switches. I use my own feedback governor system that uses pulses from one of the motor wires to keep the rpm constant. I found that some users will keep pressing the UP rpm button more and more when the motor reaches it's upper limit so my software keeps adding a higher reference number which the motor simply cannot reach. I put in a few lines to check the motor rpm and only allow the user to add two steps above this. When I remove this section then this timer works fine. I added a few more steps and found that I needed at least 7 steps about the actual motor rpm and then once again this timer will work.
My scope has burnt the pc board badly in the high tension circuit so it will take a lot of fixing to repair it, and maybe I'll have to dump it and buy a new one. I'm still curious to know why this has always worked fine on the last few hundred boards, so I'll keep this timer until I can get a scope working. I don't have a logic analyser, except for the stuff on my PicKit 2 and I don't understand MPLab debugging either so I'm at a bit of a disadvantage here.
Keith R
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I've been using the Synwrite IDE for a few years now without any major hassles. My timer system for Control Line model planes has been working very well. I have my pc boards populated here in South Africa by the same reputable firm that I've been working with for many years. With my last batch of boards I seem to be getting problems with just a few boards. I have a simple program for setting the motor rpm up or down that has worked since 2009. Now I have a few boards that simply will not allow me to set this rpm. I thought that there could be some I/O errors on the board for the 3 pushbuttons that I use so I checked the boards for continuity and all was o.k. I then wrote a short program to check the buttons. I have an LED on the board so I just used that as an indicator. All button circuits are good. Then I imported an old file that was compiled on the old version of GCB before Synwrite came out. The old program runs just fine. This is weird because the latest files work perfectly on most of the boards, Any idea's as to why this is happening? I would really appreciate any help. Thanks very much.
Regards,
Keith R
I have had this problem myself, and it can very frustrating. Could be timing issues, GCB system variable, a .dat file issue, or? Sketchy buttons? And, check for solder bridges always on the hardware side.
What version of GCB that works? What version of GCB that gives the problems? Supply the device used and cutdown version of program that shows the problem.
Debug methods I use.
1. An output of the variables in the suspected code to a terminal.
2. Use an led to see if code processes conditional logic, and jumps to subs or interrupts properly .
3. Interrogation of the assembly output
P.S. Also swap good board mcu over to bad board to see if the 16f684 is duff?
Last edit: kent_twt4 2017-12-24
Agree with Kent. We need a lot base information to really help.
Hi Kent,
Thanks as always for the quick reply. The parts are all smd so I can't just change the chip unfortunately. I also wanted to watch the signals on my scope but it has blown the HT circuit so hopefully I can fix it shortly and then I'll report back.
I have now found a small bug in my code (I guess that there are many more!) that somehow effects this particular chip. It's still a mystery to me why this has not been a problem for many years with a load of pc boards. I began to think that it is a timing issue and as I said, this suspect board works with my older software. I thought that it could be a compiler issue so I went back to my old laptop which has GCB 0.9 10/2/2007 on it. I re-compiled the older versions of my program and it worked fine, so I used this to compile one of my latest versions. No joy! I then compiled the old software with the latest GCB and Synwrite and this too worked fines, so I knew that it was not a compiler issue.
After checking the differences in my old and newer software, I only found one section that effects this suspect pc board. My timer system for control line models sets the rpm to the ESC (Electronic Speed Controller) for brushless dc motors. The user can set the rpm up or down one click at a time with 2 pushbutton switches. I use my own feedback governor system that uses pulses from one of the motor wires to keep the rpm constant. I found that some users will keep pressing the UP rpm button more and more when the motor reaches it's upper limit so my software keeps adding a higher reference number which the motor simply cannot reach. I put in a few lines to check the motor rpm and only allow the user to add two steps above this. When I remove this section then this timer works fine. I added a few more steps and found that I needed at least 7 steps about the actual motor rpm and then once again this timer will work.
My scope has burnt the pc board badly in the high tension circuit so it will take a lot of fixing to repair it, and maybe I'll have to dump it and buy a new one. I'm still curious to know why this has always worked fine on the last few hundred boards, so I'll keep this timer until I can get a scope working. I don't have a logic analyser, except for the stuff on my PicKit 2 and I don't understand MPLab debugging either so I'm at a bit of a disadvantage here.
Keith R