Setting Special Function Registers in PIC18F26K20 and XC8 C

[ocset]

Hello,
We are using a PIC18F26K20 in our simple DALI dimmable lamp.
Our software engineer used XC8 C in MPLAB X IDE.

His code does not have any mention of the ANSEL, ANSELH, INTCON or INTCON3 registers.
Is this allright?
We want RA1 and RA2 as analog inputs (ADC ). All the other pins we want as Digital I/O.
He also said he didn’t need to set the INTCON or INTCON3 registers because he wasn’t using them. (I thought you haD to disable interrupts in the INTCON register if you are not using them?…GIE=0;)

One of the PCBs is working and some work intermittently, most don’t work.

PIC18F26K20 Datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/41303G.pdf

[JPortici]

If you check the datasheet you'll see that the reset states for TRIS is all inputs, ANSEL is Anakog function on all pins and GIE is 0.

If you ask me, i don't think it is good practice. Even thought it should work, it surely is less clear to somebody else... and for what? 10 program words at most that you need to run at initialization? Jeez.

[AndyC_772]

It may be bad practice to ignore such important registers, but they do power up to defined states.

If some, but not all, of your boards are working, then the problem is unlikely to be to do with these registers. They should all either work, or not work.

Quite how anyone is achieving digital I/O without programming ANSEL is beyond me.

[BrianHG]

Could it be the PCBs?
Are all the unused IO output enabled, driven, or, tied to VCC or GND?
Is his crystal properly tuned with the right cap and resistor load and oscillator setting?
How does his circuit guarantee a true mclr reset on power-up, so that the interrupts are disabled (mclr disables GIE)?
Does he have the power-on reset timer & brown-out fuses set, or does he properly drive the mclr pin in place of these settings?

There are just sooooo many other question I can ask with such a small set of specks you have given besides a Microchip datasheet....
We need to know more before we can diagnose any of this effectively.

Example:
What the VCC, or power source?
If the brown-out bits are set, is the brown-out voltage set too close to the actual VCC?

It's a little difficult when you tell us only a few PCBs work, yet, there is the same code in each.

[NorthGuy]

If you have a software engineer, don't question what he's doing, rather demand that he make it work. If he can't, fire him and hire another one.

BTW: PIC18F25K42 has hardware support for DALI, not to mention lots of other good things.

[ocset]

Thanks,
We have Vdd = 2V5, brownout is 1V8.

If we are to be using interrupts then must we set INTCON? , or can we just rely on its default value at power up to enable interrupts (GIE = 1;)?

[ocset]

Are all the unused IO output enabled, driven, or, tied to VCC or GND?

They are now, at first the software guy mad a mistake, and we had to correct his TRIS's

[AndyC_772]

If we are to be using interrupts then must we set INTCON? , or can we just rely on its default value at power up to enable interrupts (GIE = 1;)?

Just set the damn register!

Unless you've used every last word of Flash, there's no reason at all not to set it explicitly to what you want. It *may* not be necessary, but at least it's clear to whoever is trying to read and debug the code, that it's set correctly and you've not forgotten it.

Are you sure GIE = 1 by default? I wouldn't design a processor that way. Never enable an interrupt until you've set up a handler for it.

[mikerj]

Have you either cleared the LVP config bit, or pulled the PGM pin low?  Having the PGM pin floating with LVP (low Voltage Programming) is a recipe for trouble.

[KL27x]

They are now, at first the software guy mad a mistake, and we had to correct his TRIS's

   
Are you by any chance copying someone else's code and trying to get us to help you make it work on your own product?

You have started several awful threads about this problem, picking at straws and red herrings and it seems like your "software guy" has gone on sabbatical or has died.

We want RA1 and RA2 as analog inputs (ADC ). All the other pins we want as Digital I/O.

If you pay some guy to only configure your microcontroller, so you can program the rest, please give me a job. I'm available and can take 10 minutes to look at a datasheet.

If you really have a software guy, he needs to know the problem you are having. The actual data with the actual numbers and sample sizes and everything. The schematic, if you altered it. And like he needs to know what you want the product to do... not that you want interrupts or digital I/O. That's for him to figure out. Do you have the initial batch of prototypes, design files, and code that you guys OK'd when you ordered 1000 of them? Can you revert to whatever version worked? Surely this worked at some point before you ordered 1000 boards.

Why open different threads for the same problem? There were a lot of basic troubleshooting steps posted in the other thread, which you have apparently ignored. Debugging something like this is time-consuming. Skipping steps and making assumptions will just send you down never-ending rabbit holes. Progress is going to be slow, but if you do it systematically, at least you are moving in the right direction.

Is your software engineer incompetent? Well, unless you want to pay someone for a second opinion to review the source code, you might want to first make sure it's software and not hardware. If you're the guy "fixing" the software, please stop. Based on what you have posted, you are 1000x more likely to create a new bug than to fix the problem. This is not a knock on your coding skills. For you to be able to fix someone else's code, you will need to be more than just a competent coder. You will have to be better than good enough to have written this code, yourself. And you will need time, perhaps a lot of it, in order to systematically debug and proof the final code. Unless you're hoping to luck out and randomly hit on the right straw, which seems to describe your debugging process. If you think you can just look and guess without full understanding, you're probably going to be wrong. Even IF you are the guy that wrote the code, you are going to have to go thru each step if you value your time. (Short of an "oops, I forgot to do this" type of obvious mistake.) Trying to take shortcuts will usually get you nowhere. If you're not debugging systematically and documenting it as you go, you are not doing anything, at all.

Changing TRIS? Make a note of this. But until you resolve the primary issue, don't use this version for your debugging. There may be interdependencies you do not realize, yet. The one working board works with unaltered code, correct? Stick with this version for the debugging and add and test your other improvements, later.

Have you even sent this guy a sample of the production boards, yet? Or is he just an anonymous email address and paypal account?