PDA

View Full Version : Does 16F628a support debugging or not?



queenidog
- 30th May 2012, 21:03
Simple question, please don't answer if you DON'T know!

Does 16F628a support IDC or not?

I Googled the question and found 1/2 say it does, 1/2 say it doesn't. Microchip says it doesn't unless you have a daughter board, but Microcode Studio Plus supplies a file to support the 16F628a. So I'm confused.

I built a Max232 circuit to interface to the 16F628a (which has a USART on chip), but it doesn't work and I verified sending data to the chip with a scope.

Yes or No?

Darrel Taylor
- 30th May 2012, 22:48
The 16F628A does not have a built-in hardware debugger.
So what Microchip said is true if you are using one of their programmers as a debugger.

And anyone that said you can debug a 16F628A with MicroCode Studio was also correct, because MicroCode uses software debugging via the USART and doesn't need a hardware debugging module.

You can use the serial communicator in MicroCode Studio to verify operation.
Connect to the port at 19200 baud and send a lowercase 'h'.
If everything is working properly, it will respond with a 6 digit hexadecimal number.

Make sure you have compiled the program using the "ICD Compile" or "ICD Compile Program" buttons.

queenidog
- 31st May 2012, 14:20
Thanks Darryl, this is exactly the answer I was looking for and even included a hint for something to check. I did check, didn't get the response expected so I'm looking elsewhere for the problem.

queenidog
- 31st May 2012, 18:58
I went back to the simplest circuit I could make with minimal programming just to test the ICD but I still can't get it to work. I have checked that when I send out a character to my Max232 chip that the signal gets level corrected and sent to the Rx pin of the 16F628a.
When I "Compile Program" using MCS+ the LED (code below) blinks as required. When I "ICD Compile Program" the blinking stops, and I get a time-out error when I try to run the debugger.
Using the serial communicator in MCS+, I can send out the character "h" but I get nothing returned. the Bytes TX count goes up by the number of characters I send out and curiously (because I don't know the cause), the Bytes RX count continuously increments rapidly to 16000+ and doesn't quit until I

Question: Is there anything else I have to do to get the ICD working? (perhaps a config word or register setting?)
Question: What data am I receiving (RX of 16000+)
Question: Why does execution stop (ie LED stops blinking) when I "ICD CompileProgram"?

Program is here:
TRISA = %00000000 'ALL OUTPUTS
TrisB = %00000010 'Rx on b.1, pin 7 and Tx on pin 8
#config
__config _INTRC_OSC_NOCLKOUT ; for 16F628
#endconfig
START:
High PORTA.6 'ON LED
Pause 1000
Low PORTA.6 'OFF LED
Pause 1000
GoTo START 'REPEAT

HenrikOlsson
- 31st May 2012, 19:24
It sounds to me as if the PIC never starts up properly, the TX-pin on the PIC never becomes an output so it floats which probably makes the MAX232 output "the wrong" idle state on its output to the PC so the PC keeps "receiving" bytes. Try forcing the TX output on the PIC into the correct state with a resistor. I believe the correct idle state of the TX-line is high and because the MAX232 inverts the signal you should pull it low but I might have that the wrong way around.

Now, this doesn't adress the real problem of WHY the PIC doesn't start up properly, have you measured or scoped the voltage on the MCLR-pin to verify that it's not kept in reset?

/Henrik.

Darrel Taylor
- 31st May 2012, 20:32
Your __config line doesn't have enough options in it ...

#CONFIG
__config _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_ON & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF
#ENDCONFIG


When using #CONFIG/#ENDCONFIG, ALL defaults are overridden and you must supply ALL config options.
The way it was would have left LVP ON.

This program with a 16F628A in an melabs LAB-X3 board, works fine with the ICD.

#CONFIG
__config _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_ON & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF
#ENDCONFIG

DEFINE OSC 4

LED1 VAR PORTB.4
CMCON = 7

Main:
HIGH LED1
PAUSE 500
LOW LED1
PAUSE 500
GOTO Main


But the ICD will never work if RS232 comms are not working.
Here's a simple LoopBack program. Compile it with the normal "Compile Program" button.
Use Serial Communicator at 19200, and whatever you send should be returned.
Once you get that working (strictly a hardware issue), the ICD will work.

#CONFIG
__config _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_ON & _BOREN_OFF & _LVP_OFF & _CPD_OFF & _CP_OFF
#ENDCONFIG

DEFINE OSC 4

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 12 ' 19200 Baud @ 4MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

Char VAR BYTE

CMCON = 7

Main:
HSERIN [Char]
HSEROUT [Char]
GOTO Main

queenidog
- 1st June 2012, 14:42
First I did as Henrik suggested, trying to pull down the Tx line (100 ohms, didn't work). The MCLR is high, not reset.

Then I changed the Config statement per Dave, in my own program. Didn't change anything: LED blinks when normal compile, but won't blink on ICD compile.

So I ran Dave's program but my PortA.7 (since LED was there). His had CMCon=7, otherwise program is the same. Got same results. So I used EXACTLY Dave's program ie PortB.4 and still the same results.

Bottom line: program works when I normal compile, doesn't work when I ICD compile.

NOTE: the RS232 lines were NOT connected whatsoever, the power for my breadboarded circuit (the 16F628a) is from the LABX-1 to make sure it's clean power, and the CONFIG statement Dave provided cannot have the CPD_OFF fuse because it doesn't exist in a 16F628A.INC file. The program won't compile with CPD_OFF in the string.

I noted that an ICD compile REALLY adds a LOT of overhead to the ASM file. Could this extra code be trashing memory?

I don't understand how your program can work on a 16F628a whereas mine won't even compile. I tried a DIFFERENT chip and get the same results.

I haven't done the loopback yet for obvious reasons.

Darrel Taylor
- 1st June 2012, 16:43
Dave's not here maaann.

What version of PBP3 do you have?
The current version is 3.0.5.x
http://pbp3.com/download.html

What version of MPLAB do you have?
Current version - 8.85
The latest PBP3 will install MPLAB 8.84

queenidog
- 2nd June 2012, 00:09
Sorry Darrel...I know another guy named Dave Taylor.
I have MCS 5.0.0.3
PBPX 3.0.1.4
MPLAB 8.73

Since I'm grasping at straws here, I will do all the updates.

BTW, Ran the serial test program you sent me. No matter what character I send out, I get a weird character back, like it's a baud rate problem. I changed baud rates in software to 9600 and the serial comm to same but it still gives same results. I tried even lower rates, no different. My PC serial card was set for 9600 baud, changed it to 19200 and the program and communicator to same. Same results. Type h, get back an "e" with back slanting accent.

queenidog
- 2nd June 2012, 00:41
Darrel, I upgraded MPLAB, MCS+ and PBP3.0 as required. No change.
However, I changed power supply to my circuit, the 16F628a and MAX232 chip. Instead of using the limited power supply of the LabX1, I used my other supply, a switching walwart supply. NOW my serial communicator works first time everytime. Type an "h", get an "h".
Obviously I was stressing the LabX1 supply and must have caused it to clip or get noisy.

Still have the compile ICD that doesn't work.

queenidog
- 3rd June 2012, 23:54
I have since got my program working on the 16F628 and DO NOT NEED the ICD to troubleshoot it, but I really want to make it work non-the-less for future.

My serial input works. ICD compile works to the point where I can compile and program, but when I hit RUN, it errors out with a timeout error.

ICD compile works okay with my 16F887 on the LabX1 board.

Any ideas?

Darrel Taylor
- 4th June 2012, 04:03
and the CONFIG statement Dave provided cannot have the CPD_OFF fuse because it doesn't exist in a 16F628A.INC file. The program won't compile with CPD_OFF in the string.
...

I have MCS 5.0.0.3
PBPX 3.0.1.4

...

Darrel, I upgraded MPLAB, MCS+ and PBP3.0 as required. No change.

Are you saying that you still can't compile with _CPD_OFF in the config line, even after updating?
If so, you may be compiling for the wrong chip.


My serial input works.
And what about the loopback? Do you have that working.

queenidog
- 5th June 2012, 00:21
If I put CPD_OFF in the config line, it will not compile, gives me an error that "symbol not previously defined". I looked it up in the .INC file and there is no CPD_OFF key. When I remove it from the CONFIG statement, the program compiles.
I have loopback working.
I'm compiling for a 16F628a chip. I have 2 circuits with the same chip, one is in the PCB I made, the other is just breadboarded and connected to the MAX232 serial chip to my PC. The latter is for testing.
If I ICD compile to the latter circuit, all works well until I RUN and then I get a time-out error. So I'm not even at the point where I can use the serial connection and ICD software.

Current software: MCS+ 5.0.0.3
PBPX 3.0.5.4
MPlab IDE 8.84
MPLab Suite -XC32 8.84

Darrel Taylor
- 5th June 2012, 02:13
Something doesn't add up.
This is from the p16F628a.inc file from MPLAB 8.84
_CPD_OFF is defined, and it compiles fine with the stated config lines.


_LVP_OFF EQU H'3F7F' ; RB4/PGM pin has digital I/O function, HV on MCLR must be used for programming
_LVP_ON EQU H'3FFF' ; RB4/PGM pin has PGM function, low-voltage programming enabled

_CPD_ON EQU H'3EFF' ; Data memory code-protected
DATA_CP_ON EQU H'3EFF' ; Data memory code-protected
_CPD_OFF EQU H'3FFF' ; Data memory code protection off
DATA_CP_OFF EQU H'3FFF' ; Data memory code protection off

_CP_ON EQU H'1FFF' ; 0000h to 07FFh code-protected
_CP_OFF EQU H'3FFF' ; Code protection off



Did you re-boot your computer after installing?
There is an MPASM-MPLAB Setup that runs once on booting that connects PBP3 to the MPASM path.

Did you download the larger PBP3 file that has MPLAB in it?
Did you accept all the defaults during installation?

If you send the .LST file after compiling, I might be able to see what's wrong. [email protected]

queenidog
- 5th June 2012, 15:02
Problem Solved:

I discovered this BEFORE Darrel replied. He was right on, as it turned out. Here's my post before I read HIS post:

CPD_OFF was not listed in the hard copy INC file I had (dated 2011 by Microchip) for the 16F628A.

Having upgraded, I checked again, and in the 2012 version, CPD_OFF IS LISTED. So why no workee?

I never shut my computer off (put it in sleep) so I hadn't done the reboot required after the upgrade. This was confirmed when I did reboot and a PBP install window popped up asking where the assembler was.

I put the CPD_OFF switch back in the config line and it now compiles.

I haven't verified the ICD operation yet, but thought I'd get this new development out so no one would waste their time trying to figure it out.

Thanks for your patience.

queenidog
- 5th June 2012, 15:56
I hooked up the MAX232 circuit and using the loopback program can echo characters after a "normal" compile.
After an ICD compile, typing the letter "h" returns $3C04B6.
Selecting RUN on the ICD menu, pops up a box that says I'm not connected to the serial port, which of course is incorrect, since I can loopback typed characters.
Getting closer!
What is significance of the returned hex value (just curious)?

Darrel Taylor
- 5th June 2012, 16:32
Each time you compile a program for ICD, MicroCode Studio generates a new "handshake" number so that it can match the program in the chip to the program on the PC.

After using Serial Communicator, be sure to Disconnect before trying to use the ICD in MCSP.
MCSP cannot connect if Serial Communicator is using the port.

queenidog
- 5th June 2012, 23:39
Regarding the quote, I guess since I made lots of mistakes, I made SOMETHING.

SUCCESS! I can ICD compile and debug my program on a 16F628a

I wasn't using the full config string as you had said is necessary because #CONFIG sets everything back to default.
My bad habit of doing this: TRISB=%0000000 instead of really looking at what the pins are doing got me. PortB.1 is Rx and is an input, not an output. I've been doing outputs-only for so long, it never dawned on me I'd need an input...
Thanks again for your support and your suggestions. It made me really want to fix this thing to the point where I was anal about it. The advice you gave is much better than those who say, "RTFM".

The serial loop back program was really good too because it allowed me to verify my circuit, comm from PC, comm to chip. Good stuff.

Darrel Taylor
- 6th June 2012, 20:42
Great!
I'm glad you got it working.
And I'm glad I could help. :cool: