PIC16F15376 RA7 and RD5 problems: Resolved

[Roger Jönsson]

I can not get RA7 to work at all. No input, no output and no ADC values.
For the RD5 I can not get ADC to work, normal in and out works.

I have tested this both with the PIC16F15376 stand alone chip (programmed with PICKIT3) and the MPLAB® Xpress PIC16F15376 Evaluation Board. Same thing. I though the Xpress was busted with I could not get A7 to do anything, but it was the same with another standalone chip.

I am using the GCB I downloaded beginning of January (with Synwrite 6.22.2290).

A simple bliny to test A7. D0 and D5 blinks A7 is dead.

chip 16F15376

Do forever
set PortD.0 off
set PortD.5 on
set PortA.7 on
wait 250 ms
set PortD.0 on
set PortD.5 off
set PortA.7 off
wait 250 ms
loop

[jackjames]

If you have correctly set the TRISA register I think the problem is due to the micro.
Did you verify the assembler code generated by the compiler?

[Roger Jönsson]

No, I just wrote GCB in Synwrite and exported the hex-file, then "burned" it into the chip with mplad_ipe and dropped the file onto the MPLAB Xpress. Both showed the same problem.
I can see in the assembler (I'm, not good with assembler) that the TRIS bits are set, maybe there is something missing ( but in my larger program A0-A6 are working fine, while A7 is not).

;Automatic pin direction setting
    bcf TRISD,5
    bcf TRISD,0
    bcf TRISA,7

(The full assembler file for the blinkytest is attached.)

BTW I am using nearly all the other ins and outs, without a problem. Most of them are A/D inputs, but I couldn't use A7 And D5 for that...

[Trev]

Have you setup the internal oscillator? It's not clear from your first post - there's no OSC config line and the chip line has no speed attribute.

[Anobium]

http://gcbasic.sourceforge.net/newfiles/gcbasic.exe

This is a change to hopefully resolve, I made the change last Wednesday. Change #885: Revised config default in CalcConfig to set the FOSCEXT default as OFF.

Note: I have removed the EXE has Roger has downloaded.

[Anobium]

Keeping this very simple.

This works with the compiler in the link above. I have tested on real part. Please test with the new compiler and let us know the results.

  #chip 16F15376

do
    set PortD.0 off
    set PortD.5 on
    set PortA.7 on
    wait 250 ms
    set PortD.0 on
    set PortD.5 off
    set PortA.7 off
    wait 250 ms
loop

[Anobium]

The ADC issue is resolved. Thank you for finding this typo in the library.

Download https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/a-d.h?format=raw and replace the existing file with this new file and all will operate as expected.

The root cause was a typo in the ADC library. So this change corrects the AN29 address by removing the typo. This prevented PORTD.5 ADC from operating as expected.

I have attached the test file I have used to confirm operating is as expected. Resutls range from 0 to 255 - this is the expected result.

[Roger Jönsson]

Thanks!
A7 now works as in/out and A/D.
However the D5 A/D still seems dead.

Test code (grounding D4 makes D1 go high, for D5 nothing happens):

#chip 16F15376
    DIR PORTD b'00110000'
    set RDPU = 0 'enabling Port B pullups in general.
    set WPUD4 = 1
    set WPUD5 = 1

Do forever
    if ReadAD(AND4) < 127 then
           set PortD.1 on
           else
           set PortD.1 off
    end if

 if ReadAD(AND5) < 127 then
           set PortD.1 on
           else
           set PortD.1 off
    end if

    loop

[Anobium]

Update the ADC library please.

Download https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/a-d.h?format=raw and replace the existing file with this new file and all will operate as expected.

[Roger Jönsson]

Sorry I wrote the above while Anobium
replied. Testing right now.

[Roger Jönsson]

Yep! Thanks! It now works!
:)

[Anobium]

Excellent.

Summary: Two issues. Both unrelated both resolved.

• The port issue is because Microchip required the FOSCEXT to be set to off - by default. So, I have revised the compiler earlier this week to add this feature.

• The ADC was a typo. Must have been a long standing typo, we failed to test and no-one else used that specific port.

Both fixes will be in the next release but if you need prior to March 2019 - please ask.

[Anobium]

I thought it would be worth explaining how I debugged the ADC issue.

I used the ADReadPreReadCommand constant. With no other changes to the code using ADReadPreReadCommand with insert whatever the constant is just before the ADC read happens.

My method.
1. Got the datasheet and looked up the value of ADCON0 to understand the value of the bits to read this ADC. #define ADReadPreReadCommand ADCON0=0x74. This worked... so, clearly the issue was with setting ADCON0.
2. Setup the serial for debuging. #define ADReadPreReadCommand HserPrint hex(ADCON0): HserPrintCRLF. This returned 0x9C!! should be 0x74.
3. Look at the A-D.h. Spotted the typo. There was a value of 39 not 29, and this made sense as these values are shifted twice to the left. So, this is 39<<2 and 29 << 2 equates to 156 (0x9c) and 116 (0x74) respectively.

Case solved. Edit and pubish the update.

ADReadPreReadCommand is very useful to resolve and debug ADC issues.

Anobium