 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Gelio
Joined: 25 Aug 2014
Posts: 12
|
| monitoring UART problem |
 Posted: Tue Sep 02, 2014 4:33 pm |
 |
|
Hi all,
programmed my PIC18F2455 with bootloader and flash.
in debug mode all working fine.
in normal mode i cannot see some debugging messages from PIC.
calling the
| Code: |
read_program_eeprom(0x1F86);
read_program_eeprom(0x1F87); |
always returns 00, in debug mode all working ok.
I'm using UART monitoring in PICKIT2 Uart tool.
read_program_eeprom(DeviceID) - returns normal data.
block 0x1000-0x2000 has bits
EBTR1=1
WRT1=1
CP1=0
according to printf()
| Code: | SN1=read_program_eeprom(0x1F86);
SN2=read_program_eeprom(0x1F87);
printf("DeviceFW Revision: %02X %02X\r\n",SN1,SN2); |
in Pickit Uart i always have:
"DeviceFW Revision: 00 00" output.
But 0x1F86:0x1F87 contains 0x01:0x05 values programmed in flash.
other memory addresses read ok, including config registers and bootblock.
Last edited by Gelio on Tue Sep 02, 2014 11:20 pm; edited 1 time in total |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Tue Sep 02, 2014 6:03 pm |
|
|
hmm...
printf("DeviceFW Revision: %02X %02X\r\n");
say HOW to print the data but not WHAT data !
I'm assuming you want to display variables SN1 and SN2 ???
jay |
|
|
Gelio
Joined: 25 Aug 2014
Posts: 12
|
|
| Posted: Tue Sep 02, 2014 11:09 pm |
|
|
Sorry. my mistyping.
of course printf("DeviceFW Revision: %02X %02X\r\n",SN1,SN2);
Always return 00 00
if CP1 set to 1 then it working fine.
But in release mode when CP1=1 then it print zeros.
EBTR1=1 so no table read protection enabled.
Do i need to adjust some configuration bits? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Tue Sep 02, 2014 11:42 pm |
|
|
I don't have the Pickit2 and never use 'debug' mode, but I suspect your program has 'ice=true' or some other code to use the UART for debugging.
This would be obvious if you'd posted your entire program.
jay |
|
|
Gelio
Joined: 25 Aug 2014
Posts: 12
|
|
| Posted: Wed Sep 03, 2014 12:48 am |
|
|
| Code: |
#include <18F2455.h>
#use delay(clock=20M) // frequence 20 Mhz
#use rs232(uart1,baud=38400, bits=8, arity=N,xmit=pin_c6,rcv=pin_c7)
#fuses 1=0x8E24
#fuses 2=0x1E37
#fuses 3=0x0000
#fuses 4=0x00C1
#fuses 5=0xC000
#fuses 6=0x0000
#fuses 7=0x400F
void main(void){
int16 SN1=0;
int16 SN2=0;
while(true)
{
SN1=read_program_eeprom(0x1F86);
SN2=read_program_eeprom(0x1F87);
printf("DeviceFW Revision: %02X %02X\r\n",SN1,SN2);
delay_ms(1000);
}
}
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19498
|
|
| Posted: Wed Sep 03, 2014 1:33 am |
|
|
Use the named fuses.
Your clock settings do not match what you are telling the compiler. You have HSPLL enabled, which means the CPU is fed off the USB PLL, but are saying that your CPU is running at 20MHz, which it isn't...
As a general comment, you have all the blocks write protected - don't do this when debugging - it forces a full device erase every time you change anything, and uses up extra lives on the chip's flash memory. Only do this for the final code.
Now you say that 0x1F86, and 87 contain values. Where?.
Because you have write protection enabled, the chip _will_ be fully erased when the code is loaded. So these bytes won't contain any values. This is the core problem....
This set of fuses gives a working system to match the rest of your code:
| Code: |
#include <18F2455.h>
#use delay(clock=20M) // frequence 20 Mhz
#use rs232(uart1,baud=38400, bits=8, parity=N,xmit=pin_c6,rcv=pin_c7)
#fuses PLL5, HS, USBDIV CPUDIV1 //CPU from master oscillator, with USB
#fuses NOFCMEN, NOIESO, PUT //you want PUT when starting from a crystal
#fuses BROWNOUT, BORV43 //brownout in hardware
#fuses NOWDT, WDT32768 //watchdog under software control
#fuses VREGEN, NOPBADEN, NOMCLR, NOLVP //wake up for digital, with Vreg etc..
#fuses CCP2B3, STVREN, NOLPT1OSC //stack full reset, no osc on T1
#fuses NOCPD, CPB, WRT, NOEBTR, PROTECT //protect as much as possible
#rom int8 0x1F86 = {0xAA, 0x55} //test values
|
The point is that when you enable code protection, then the whole chip has to be erased to write the code, so the values at 0x1f86, and 87, are lost, unless you include them in the code. I'm guessing you are actually running in a simulator, and it doesn't care that the oscillator settings were wrong (Proteus for example), hence you were able to get away with the other errors... |
|
|
Gelio
Joined: 25 Aug 2014
Posts: 12
|
|
| Posted: Wed Sep 03, 2014 2:48 am |
|
|
Ok, thanks, i will try today.
P.S. one thing.
I'm programming the BLOCK 0x000-0x7FF only after bulk erase.
other memory unchanged while programming.
think maybe when I'm connecting with UART monitor from pickit it forces the chip into debug mode... |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Wed Sep 03, 2014 8:21 am |
|
|
...
think maybe when I'm connecting with UART monitor from pickit it forces the chip into debug mode...
well that kinda makes sense as the Pickit software probably says ''hmm... need to control the UART...must be 'debugging' so I'll fore 'debug' mode....
jay |
|
|
|
|
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
