18F25K22 ICSP problem

[Peter Truman]

Hi - I'm having an intermittent problem programming a PIC18F25K22 - with the RB6 and RB7 (Tx2/PGC and Rx2/PGD) pins connected to a MAX232 chip (Texas Instruments MAX232ECDR)

I use an ME Labs U2 programmer (Ver 4.67)

Sometimes I can upload development code multiple times - all day long. Next thing I'll get a 'Target Device does not match selected device' and I'll spend half an hour trying to get past this error (the noise is very annoying :-)

I use 5 gold plated index pins for the ICSP connector on my boards - I make up a ribbon cable to suit with 5 x molex sockets (these don't last forever so I periodically replace the whole connector cable - have done so many times)

Occasionally I have to put lateral pressure on the connector to get it to work - that's when I know I need new molex sockets.

My current setup works fine 99% of the time but I have a board I'm working on which is just not cooperating - which makes me think there is something unusual about this particular design.

Also - sometimes after apparently successfully programing the IC it wont start up properly - often spitting out my 'startup message' on the debug terminal (via the aforementioned MAx232) then just hanging. (I have tried not connecting my terminal)

I have a 10k pullup on Vpp - I also tried adding a 0.1uF cap on Vpp to slow down the startup - nothing seems to help

There is nothing I can find in terms of solder problems or discontinuity - the board itself is drawing about 8ma (when it works) so shouldn't be a load 'issue'?

These particular boards cost me about Aus$2k to have made (inc assembly) for 3 boards - and all 3 exhibit this same problem - so I don't want to have any more made until I understand what is going on.

Can I ask if anyone has had any similar experiences or has any suggestion to offer?

Happy to provide more details if required

Many thanks - in advance

[ege]

Check out the diagram and document in the link below.

https://www.northernsoftware.com/dev/pic18f/pic18f25k22.htm

[trastikata]

Can you provide more information about the clock source and the code fuse and clock settings?

[RGV250]

Hi,
Have you checked the circuit shown in fig 3.1 in the pickit2 user guide. It shows series resistors required if using PGC/PGD for the application as well as prgramming.

Bob

[John Lawton]

Indeed, is the RS232 interface chip (RX) loading one of the pins, in which case you may need to try manipulating the RS232 line, although without a series resistor that might not help. You might have to arrange the programmer waveform to go via the RS232 interface instead of direct to the pin.

[Stephen Moss]

Hi - I'm having an intermittent problem programming a PIC18F25K22 - with the RB6 and RB7 (Tx2/PGC and Rx2/PGD) pins connected to a MAX232 chip (Texas Instruments MAX232ECDR)

Where does the MAX232 come into it things, is it part of the U2 programmer or externals as would there not need to be 2 of them due to RS232 devices generally inverting the data?
 
Are you are using low voltage programming mode as I cannot see how you would generate the require high voltage on the MCLR pin if just using the TX/RX pins of a RS232 device for programming?
If so then is it possible that some kind of noise/pickup on the PGC/PGD pin is occasionally resulting in the input state necessary to place the PIC into programming mode, and thus with it already being in that mode that is somehow preventing the programmer from retrieving the the device ID resulting the described error?
Perhaps try placing some decoupling caps on the PGC & PGD lines to minimise/eliminate that possibility.

[SCV]

It is the RS232 chip RXout driving over the PGD line. I put a resistor in series to the RXout pin leaving the PGD connected directly.

[top204]

It's not fully going to be your circuit at fault. I also use the U2 programmer and it has a dreadful drive circuit in it. Even slight loads on the programming pins can intermittently stop the programming. Yet, if I use another programmer, it goes staight through and programs the device. And as you do, sometimes putting slight pressure on the ISCP connecter makes the device program, because the pressure is causing a better connection within the plug/socket of the ICSP pins, so it can counter-act the poor drive circuit a bit better.

However, it has gotten to the stage where I do not use the PORTB.6 or PORTB.7 pins for anything else except programming. UART to USB drive devices do put quite a load on pins, so you can try series resistors of 470 Ohm to 2.2K Ohm from the RB6 and RB7 pins to the UART to USB converter, and this may weaken the load enough for the U2 programmer to get through, but not too weak that the serial data has problems.

It is such a shame that melabs seem to have abandoned the U2 programmer, because it so simple to use and clear to understand.

[John Lawton]

I've very happy with my U2 programmer, but MELabs seem to have abandoned almost everything, even their flagship PIC Basic Pro, it's very long in the tooth these days.



John

[GDeSantis]

PIC BASIC Pro may very long in the tooth these days; but the Microsoft Third Party Tool Category website still shows it as a viable option.

https://www.microchip.com/en-us/development-tools-tools-and-software/third-party-development-tools/third-party-development-tools-category-explorer?category=thirdpartytools/compilers

[GDeSantis]

Sorry about the typo.  I meant to say Microchip and not Microsoft.

PIC BASIC Pro may very long in the tooth these days; but the Microchip Third Party Tool Category website still shows it as a viable option.

https://www.microchip.com/en-us/development-tools-tools-and-software/third-party-development-tools/third-party-development-tools-category-explorer?category=thirdpartytools/compilers

[Peter Truman]

Can you provide more information about the clock source and the code fuse and clock settings?

Sure - this is my setup.

Code Select Expand

Device = 18F25K22

Config_Start
  FOSC = INTIO67    ;Internal oscillator block
  PLLCFG = On    ;Oscillator used directly
  PRICLKEN = On    ;Primary clock enabled
  FCMEN = OFF    ;Fail-Safe Clock Monitor disbled
  IESO = On  ;Oscillator Switchover mode disabled
  PWRTEN = On    ;Power up timer enabled
  BOREN = SBORDIS    ;Brown-out Reset enabled in hardware only (SBOREN is disabled)
  BORV = 190    ;VBOR set to 1.90 V nominal
  WDTEN = On    ;WDT is always enabled. SWDTEN bit has no effect
  WDTPS = 1024    ;1:32768
  CCP2MX = PORTC1    ;CCP2 input/output is multiplexed with RC1
  PBADEN = OFF    ;PORTB<5:0> pins are configured as digital I/O on Reset
  CCP3MX = PORTB5    ;P3A/CCP3 input/output is multiplexed with RB5
  HFOFST = On    ;HFINTOSC output and ready status are not delayed by the oscillator stable status
  T3CMX = PORTC0    ;T3CKI is on RC0
  P2BMX = PORTB5    ;P2B is on RB5
  MCLRE = EXTMCLR    ;MCLR pin enabled, RE3 input pin disabled
  STVREN = On    ;Stack full/underflow will cause Reset
  LVP = On    ;Single-Supply ICSP disabled
  XINST = OFF    ;Instruction set extension and Indexed Addressing mode disabled (Legacy mode)
  Debug = OFF    ;Disabled
  Cp0 = OFF    ;Block 0 (000800-001FFFh) not code-protected
  CP1 = OFF    ;Block 1 (002000-003FFFh) not code-protected
  CP2 = OFF    ;Block 2 (004000-005FFFh) not code-protected
  CP3 = OFF    ;Block 3 (006000-007FFFh) not code-protected
  CPB = OFF    ;Boot block (000000-0007FFh) not code-protected
  CPD = OFF    ;Data EEPROM not code-protected
  WRT0 = OFF    ;Block 0 (000800-001FFFh) not write-protected
  WRT1 = OFF    ;Block 1 (002000-003FFFh) not write-protected
  WRT2 = OFF    ;Block 2 (004000-005FFFh) not write-protected
  WRT3 = OFF    ;Block 3 (006000-007FFFh) not write-protected
  WRTC = OFF    ;Configuration registers (300000-3000FFh) not write-protected
  WRTB = OFF    ;Boot Block (000000-0007FFh) not write-protected
  WRTD = OFF    ;Data EEPROM not write-protected
  EBTR0 = OFF    ;Block 0 (000800-001FFFh) not protected from table reads executed in other blocks
  EBTR1 = OFF    ;Block 1 (002000-003FFFh) not protected from table reads executed in other blocks
  EBTR2 = OFF    ;Block 2 (004000-005FFFh) not protected from table reads executed in other blocks
  EBTR3 = OFF    ;Block 3 (006000-007FFFh) not protected from table reads executed in other blocks
  EBTRB = OFF    ;Boot Block (000000-0007FFh) not protected from table reads executed in other blocks
Config_End

OSCCON.6=1
OSCCON.5=1
OSCCON.4=1
OSCTUNE.6=1                                                                                'disable the 4x PLLEN

Xtal = 64

PinPullup Enable,PORTB                                                                      'Turn on Port B Pullups



'Declare Create_Coff=True
'setup the I2C comms
Declare SDA_Pin PORTC.4                                                                    '12C declares
Declare SCL_Pin PORTC.3
Declare Slow_Bus On


All_Digital=True                                                                            'start at digital
Declare Adin_Res 10                                                                        '10 bit result
Declare Adin_Tad FRC                                                                        'clock source
Declare Adin_Stime 100                                                                      'time to dx cap

ADCON1.3=0                                      'select +Ref as external pin
ADCON1.2=0                                      '}
ADCON1.1=0                                      'select -Ref as Vdd
ADCON1.0=0                                      '}
ADCON2.7=1                                      'RIGHT justified  for a 10 bit result
INTCON.7=0

ANSELA.5 = 1                                    'set portA.5 to analogue
ANSELA.3 = 1                                    'set PORTA.0,1,2,3 to analogue (no analogue on portA.4)
ANSELA.2 = 1
ANSELA.1 = 1
ANSELA.0 = 1

'Setup USART 1 (Tlit Module)
Declare Hserial1_Baud = 115200
Declare Hserial1_Clear = 1                                                                  ' Enable Error clearing on received characters
Declare HRSOut1_Pin = PORTC.6
Declare HRSIn1_Pin = PORTC.7

'Setup USART 2 (Real World)
Declare Hserial2_Baud = 115200
Declare Hserial2_Clear = 1                                                                  ' Enable Error clearing on received characters
Declare HRSOut2_Pin = PORTB.6
Declare HRSIn2_Pin = PORTB.7


Declare RSOut_Pin=PORTA.6                                                                  'LCD Data
'Declare RSOut_Mode=true
Declare RSOut_Mode=inverted
Declare Serial_Baud 9600
'Declare Serial_Baud 14200                                                                  'toggle test with 2000ms shows 2.0022s


Symbol  _AnIN_1    = PORTA.0
Symbol  _AnIN_2    = PORTA.1
Symbol  _PWR_On    = PORTA.3
Symbol  _Loop1      = PORTA.4
Symbol  _Loop2      = PORTA.5
Symbol  _Loop_Alm  = PORTA.7
Symbol  _IOInt      = PORTB.0
Symbol  _RTCInt    = PORTB.1
Symbol  _Menu      = PORTB.2
Symbol  _Up        = PORTB.3
Symbol  _Dn        = PORTB.4
Symbol  _Enter      = PORTB.5
Symbol  _Tlt_Mon    = PORTC.0
Symbol  _Tlt_On    = PORTC.1
Symbol  _Tlt_HW    = PORTC.2
Symbol  _Piezzo    = PORTC.5

TRISA  =%10111101
TRISB  =%00111111
TRISC  =%10000000


[Peter Truman]

Hi,
Have you checked the circuit shown in fig 3.1 in the pickit2 user guide. It shows series resistors required if using PGC/PGD for the application as well as prgramming.

Bob

Thanks Bob - I'll check this out - although I have a number of projects that share the Tx2/Rx2 with PGD/PGC pins and haven't come across this previously.

[Peter Truman]

Hi - I'm having an intermittent problem programming a PIC18F25K22 - with the RB6 and RB7 (Tx2/PGC and Rx2/PGD) pins connected to a MAX232 chip (Texas Instruments MAX232ECDR)

Where does the MAX232 come into it things, is it part of the U2 programmer or externals as would there not need to be 2 of them due to RS232 devices generally inverting the data?
 
Are you are using low voltage programming mode as I cannot see how you would generate the require high voltage on the MCLR pin if just using the TX/RX pins of a RS232 device for programming?
If so then is it possible that some kind of noise/pickup on the PGC/PGD pin is occasionally resulting in the input state necessary to place the PIC into programming mode, and thus with it already being in that mode that is somehow preventing the programmer from retrieving the the device ID resulting the described error?
Perhaps try placing some decoupling caps on the PGC & PGD lines to minimise/eliminate that possibility.

Im sharing the RX2/Tx2 pins between the ICSP header and the MAX232 - so programming in the normal way, with LVP enabled by default. I've tried getting past this problem by having nothing connected to the MAX232 so I wouldn't expect there to be any noise - but there may be some DC bias (I'll have a poke around) - certainly worth trying a couple of caps to GND, as long as they are not large enough to affect the programming signal rise time - I'll start with a few pF and see if it helps.

Thanks for the suggestion

[Peter Truman]

However, it has gotten to the stage where I do not use the PORTB.6 or PORTB.7 pins for anything else except programming. UART to USB drive devices do put quite a load on pins, so you can try series resistors of 470 Ohm to 2.2K Ohm from the RB6 and RB7 pins to the UART to USB converter, and this may weaken the load enough for the U2 programmer to get through, but not too weak that the serial data has problems.

Yes - I do the same. Mostly I don't need to use these pins for anything else so I just reserve them for programming - programmed hundreds of boards that way. This project however calls for 2 USARTS plus an additional serial pin to drive an LCD - I'm using interrupts on both the USARTS so I didn't have much choice.

I have another board which I designed that uses a PIC32MZ2048EFH144-E/PL - fortunately, I'm only doing the hardware for that project. The F/W guy sent me a ICD4 programmer with a view to us collaborating on the development (he's in Sydney, I'm in Tasmania) but I haven't even worked out the toolchain I need yet - otherwise i could try that.

The problem I have is, I tend to 'fall back' on what I am most comfortable with - I've been using Proton through it's various predecessors for getting on for 20 years so every time I have a project I decide I should learn C or Python or whatever, I get fedup and frustrated and decided that there is nothing wrong with doing it the way I've always done it - the outcome is the same anyway LOL (even if it's not as efficient as it could be). Same with the U2 programmer - maybe I should run the PGD and PGC signals though a simple buffer - CD4050 or something, wonder if that would help?

[Peter Truman]

STVREN = On    ;Stack full/underflow will cause Reset
  LVP = On    ;Single-Supply ICSP disabled
  XINST = OFF    ;Instruction set extension and Indexed Addressing mode disabled (Legacy mode)

Note - I have show this as 'ON' - this was my previous attempt to fix this, I normally have this 'OFF' and I have changed the chip since this example - apologies for the confusion!

[trastikata]

hanks Bob - I'll check this out - although I have a number of projects that share the Tx2/Rx2 with PGD/PGC pins and haven't come across this previously.

Looks like the MAX232ECDR has a 10mA output drive capability and when the RS-232 input is left floating, the UART output is held high.

Depending on the drive capability of ICSP programmer, 10mA might be too much and the wave form for PGD might not always be correct.

[John Lawton]

That makes sense. I don't have the schematic for the U2 programmer but it should be possible to make a current booster for the affected line to override the RS232 drive current.

[tumbleweed]

As others have said, put series resistors (> 1K, maybe larger) in the lines to the MAX232, and connect the U2 directly to the PGC/PGD pins. The MAX232 TX output will then look like a pullup to the U2 and it can override it. It should look similar to post #6.

Remove any caps you may have placed in the PGC/PGD lines. That will only screw up the timing.

Without a schematic of the U2 it hard to say exactly what the drive output is, but on all of the PICkit programmers PGC/PGD have 4.7K pulldowns to GND, so keep that in mind in case the U2 has something similar.

LVP doesn't come into play here, and the only signal that will be >5V is the MCLR line which will be raised to about 13V when it enters programming mode.

[John Lawton]

The OP said "These particular boards cost me about Aus$2k to have made (inc assembly) for 3 boards - and all 3 exhibit this same problem - so I don't want to have any more made until I understand what is going on."

So he probably isn't able to modify these boards, adding resistors, he needs a fix which is what I suggested.