set_tris_b using PIC16F716 and ICD2 not working

[edbfmi1]

I am just begining to use the CCS compiler with an ICD2 debugger.

I have a very simple program that I have written to get familiar with this setup.

The problem is when I try to setup the ports.

I try to set PORTAs trisa as 0x1f and PORTBs trisb as 0x37.

Then all I want to do is read pin PIN_B4 and set PIN_B7 high if PIN_B4 is high and low if PIN_B4 is low.

When I step through the program and watch the tristate registers in a watch window in MPLAB 8.10 they are set to all zeros when the program executes the set_tris_a and set_tris_b commands.

Any ideas???

[Ttelmah]

Start by looking at the data sheet. TrisA, is memory address 0x85, and TrisB is address 0x86. On the '16' chips, you can't wite directly to addresses over 0x7F, so addressing these will be done by talking to addresses 5, and 6, with bank 1 selected (which adds 0x80, to the address you actually talk to). To select Bank1, you need bit5, of register 3, set, and bit6 clear (both of these 'wake up', set to '0').
Now look at the assembler:
Line 8, sets bit 5 of register 3, as required. Nothing after this, to the 'tris' instructions, changes this.
Line C, puts '1F', into the accumulator, and then line D, writes this to address 5, _which addresses 0x85_, with the bank select set. Exactly what you have asked it to do.
Then line E, puts '37', into the accumulator, and line F, writes this to the TrisB.

The code is doing what you want it to do. If you are not seeing what you expect, 'look again', at what else you are doing.....
I'd suspect a problem with the ICD, or the interface with MPLAB.

As a 'minor' comment, for 4MHz, select XT, rather than HS in the fuses.

As a further comment, you don't actually have to do this at all. By 'default', the CCS compiler, will _automatically_ set the TRIS bit for every bit you use as an input, and clear the TRIS bit for everything you use as an output. Lines 26, and 27, do this for the input bit 'AC'. If you want to control the TRIS manually, use the #use fast_io option for the port. However unless you need this, why not just let the compiler do it's job....

Your problem is not in the code shown, but something in the way your development environment is working...

Best Wishes

[edbfmi]

Thanks for the input Ttelmah.

I read through the assembled code and did not see anything myself.
I also wrote the program without using the "tris" commands.
It still compiles correctly but when I debug it and watch the trisa and trisb registers they randomly switch to all outputs??
Also when I get to the

[PCM programmer]

The first thing to do, is to go to the MPLAB "Configure" menu, and
open the "Select Device" window. Make sure that the device is
really set to "16F716".

[edbfmi]

I did check to make sure the device selected is the PIC16F716.
I wish it were that simple. Still no luck.

I am beginning to question the actual ICD2 module.

Along those lines, has anybody had any luck eith the RealICE emulator?

I need to get this project off the ground and can't spend a lot of time messing around with hardware issues.

[edbfmi1]

I just tried something that may help someone figure out what is going on.

I did FILE>IMPORT and imported the .hex file. When I did that the program seemed to run fine on my hardware. I could step into the program and watch the PORTB inputs change as I changed them on the target. Unfortunately when I do it this way I can't watch the Code Step through the program lines in the MPLAB window.

Does this shed any light on my issues?

[ckielstra]

[Ttelmah]

It sounds as if the .cod file has problems, so the ICD, is not receiving the real information about the code. If I remember correctly, in the early days of the V4 compilers, the default settings in CCS, did not output the file in the format needed by MPLAB. This was changeable. However I have to 'second' the suggestion to move away from 4.011...

Best

[edbfmi1]

Thanks for the insight.

One other thing I have tried that seems weird.

I moved the

[Ttelmah]

3.249, is still available from the download page, for exactly this reason....

Do you have the 'windows' environment, or the command line version?.
In the windowed version, 'Options', 'Project options', 'Output files'. The problem with ICD, was I think, to do with whether you selected 'Standard .COD', or 'Expanded .COD'. There were posts here about it when V4 was young.

Have a separate look at the 'Version 4 comments' sticky thread at the top of the forum. Posting in it really 'died' when V4, started to work. 4.011, was really still at the point in the V4 development, where it hardly worked....

Best Wishes

[edbfmi1]

Well I just got version 3.249 installed and I am having the exact same issues.

I think I am going to get the Microchip RealICE on order today and have it flown in. I need to get past this so I can get this board developed.

I will keep everyone advised on the progress (or lack of)

[PCM programmer]

Are you using the special header that is required to do hardware
debugging with the 16F716 and the ICD2 ?

Download the ICD2 header specification and look at the table on page 12.
It shows that header p/n AC162054 is required. ("N" means it's needed).
http://ww1.microchip.com/downloads/en/DeviceDoc/51292P.pdf
I hope you don't go spend a couple thousand dollars when all you really
needed was a header.

[edbfmi1]

Yep, I am using the header.

I agree, I really don't want to part with the extra$$$ if I don't have to.
(I can use it for GASOLINE )

But as I sit now I feel like I am dead in the water and need to try something to get this project moving forward.

[PCM programmer]

Why not do the development on a closely similar PIC that has built-in
debugging ? (And doesn't require a header). Debug it on that PIC.
Then move the completed project to the 16F716. Re-compile it for that
PIC and it will probably work.

[edbfmi1]

That is a possibility.

I might give that a try as plan A. I am still going to get the RealICE in here tomorrow for Plan B. I just won't open it unless Plan A becomes too much of a bother.

I will keep you all posted.