 |
 |
| View previous topic :: View next topic |
| Author |
Message |
esteban
Joined: 01 Sep 2007
Posts: 13
|
|
 Posted: Mon Sep 03, 2007 2:21 pm |
 |
|
I added the ERRORS directive on the two #USE rs232().
I have that done on older versions of my code, also, but done it again just now.
Same problem.
I already had the capacitors on both VDD pins (to VSS each).
I understand you checked one compilation (LST file, i guess) against the other. Am i right? But i don't know if you test it on your board, in which case i don't know if it worked for you. If so, could you send me the hex so i can bootload it on my board?
Thanks a lot, PCM programmer. I really need to solve this.
EDIT: One important thing i forgot to say is that i run this same program on 3 different units (all of them 16F877A, of course) with the same result. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Sep 03, 2007 2:32 pm |
|
|
My advice is to continue removing lines of code from your program,
to see how small you can make it, but still see the same error.
For example, remove all fast_io() and set_tris() statements.
Let the compiler handle the TRIS.
You have several statements that disable peripheral modules.
These modules are all disabled by default upon power-on reset.
You don't need to do it again.
Also, add a continuous loop at the end of your program, so it doesn't
fall off the end of main() and go to sleep. Example:
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Sep 03, 2007 2:57 pm |
|
|
I did another test.
I compiled your program with vs. 4.020 and programmed it into a
16F877A on a PicDem2-Plus board, using an ICD2 programmer.
Because my board has LEDs on pins B0-B3, instead of Port C,
I added additional lines of LED code to also toggle my LED pins,
while still toggling pins C1 and C2.
It worked. I hold down the Enter key in the terminal window, and
the LED changes state (on or Off) with each character that is sent
to the board. It never locks up. Both LEDs never go on.
I even enabled the LVP fuse. I put a 4.7K pull-down on pin B3.
I think you have too many things that are "strange" in your project.
1. You're using LVP mode. 99% of all people use High Voltage mode.
2. You're using icprog. Probably most people use either MPLAB or
the CCS IDE.
3. I think you're using a home-built board, or breadboard. Most
people probably use a manufactured board.
These three things may work, but because they are different from the
normal way, I think there is a greater possibility of error. One of them
could be causing a problem. I don't think it's the compiler, because
vs. 4.020 worked for me, at least with your program. So I don't think
I can do any more to help, or not much more .
Last edited by PCM programmer on Mon Sep 03, 2007 2:58 pm; edited 1 time in total |
|
|
esteban
Joined: 01 Sep 2007
Posts: 13
|
|
| Posted: Mon Sep 03, 2007 2:57 pm |
|
|
Here's the code stripped down, as you suggested.
| Code: |
#include "C:\Barreras\PIC\Pic_Barrera.h"
#BYTE PUERTO_C=0x07
#org 0x1F00, 0x1FFF void loader16F876(void) {} //protect bootloader code for the 8k 16F876/7
char Buffer[30];
int8 Estado;
#locate STATUS_TEMP =0x67
#locate Flag =0x68
int1 Up;
unsigned int8 LargoDatos_COM = 0;
#BIT TXIF = 0x0C.4
#define Timeout_COM_Protocolo 76 //1 Seg + o -
#define Buffer_COM_SIZE 40
unsigned int8 Buffer_COM[Buffer_COM_SIZE];
unsigned int8 Buffer_COM_Next_In = 0;
unsigned int8 Buffer_COM_Next_Out = 0;
unsigned int8 Estado_COM = 0;
unsigned int8 ContadorCaracteres_COM = 0;
int1 COM_Procesando_Comando = 0;
int1 BUFFER_OVERRUN = 0;
int1 COM_Dato_Valido = 0;
int1 ContarTimeout_COM = 0;
char Identificacion[10] = "Carrera ";
char INFO_Unidad[2];
unsigned int16 Timeout_COM_Protocolo_Contador = 0;
unsigned int16 Contador_Timeout_1 = 0;
#INT_RDA
void RDA_isr()
{
getc();
Up = 0;
}
void main()
{
int1 Bucle;
int1 dumb1;
unsigned int8 dumb2;
unsigned int8 dumb3=0;
unsigned int16 dumb4=0;
unsigned char Mem[2];
setup_uart(0);
#use rs232(baud=38400,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8, stream=SERIAL, ERRORS)
setup_uart(1);
Bucle = 1;
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
set_timer0(0);
while (Bucle==1)
{
LED_1_ON;
LED_1_OFF;
}
LED_1_ON;
LED_2_ON;
while(1);
}
|
I retain the variables in order to keep the part of the problem that i could (somehow) isolate. Particularly, the 'bucle' and 'Up' (addresses 0xC8.0 and 0x48.0). I had to replace the variable "LargoDatos_COM' inside the ISR for 'Up', because with this modifications the compiler moved the location of some variables.
About this, is what puzzles me more. It look pretty systhematic. If i set the 'Up' variable in the isr to 1, it never leaves the while (both leds never go ON).
That's what make me spin around the idea of a bank switching problem. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Sep 03, 2007 3:00 pm |
|
|
I don't think it's the compiler. See my post above, that I made just
before your last post. I was editing it just as you posted, so I don't think
you saw it yet. |
|
|
esteban
Joined: 01 Sep 2007
Posts: 13
|
|
| Posted: Mon Sep 03, 2007 3:06 pm |
|
|
Thanks a lot, again.
I'll try with another board, and see what happens. If it worked for you, it's obvious that it is not a code problem (source/compiler/whatever). I was pretty sure it was, but i'd have to look some other way.
The only difference (besides something not working on the board) is that my pulldown is 10K. Twice yours. Would that be something?
And yes, i was writing as you posted.  |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Sep 03, 2007 3:15 pm |
|
|
The 10K pull-down vs. 4.7K won't make any difference.
But make sure you don't have a secret pull-up on that pin.
(Maybe inside the programmer). |
|
|
esteban
Joined: 01 Sep 2007
Posts: 13
|
|
| Posted: Mon Sep 03, 2007 3:32 pm |
|
|
I don't have the programmer connected (is in a separated board). And have just connected RB3 to gnd (i'm not using it in the test).
Still the same.
Don't want to keep bothering you or anybody else if this is a hardware problem. By tomorrow i'll have a new board.
If i can think of something else, i'll try.
One way or another, i'll keep you up to date.
Thanks a lot. |
|
|
esteban
Joined: 01 Sep 2007
Posts: 13
|
|
| Posted: Sun Sep 16, 2007 12:04 pm |
|
|
Hi. I'm back to let you know that i've found the problem.
It was in effect a bank switching problem. It was caused by the bootloader.
The bootloader is looking at the address of the hex file it's loading into the pic. When it finds the reset vector, it saves it for jumping to the main (of the loaded program). Each time you reset, the BL waits for 200mS, and if nothing comes on the USART, it jumps to that 'saved' reset vector. In the actual reset vector (at 0000h) it places a jump to the bootloader main.
I don't know what asm code the PICC Lite generates. I didn't use that compiler. But i can't imagine this working with or without picc lite on any 16f pic. But i don't know. So i don't know if it makes any sense or not, but a comment (in german, hard to find) inside the bootloader source, states that for 'compatibility' with picc lite 9.somethingmaybe5, it copy the first 8 bytes instead of the first 4. That makes the interrupt vector be filled with zeroes. And, of course, it doesn't save the W register nor the status register (those instructions are located in 0004h...0007h). So if you're lucky and discrete, will never notice the thing. Keep working on the bank 0 for all variables, and only interrupt when the w content ir irrelevant. Meaning: erratic behaviour. And that was what was happening to me.
Thanks folks.
Specially thanks to PCMProgrammer.
Hope this could help somebody before he/she goes bald. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
