Hi again,
I have found this a while ago but I wasn't sure whether to report it here,
or to the programmer developers (piklab), or to the assembler developers
(gpasm)... anyway, here I am.
When I read the .hex file of the program bellow into piklab I get completely
wrong (but consistent) values for the configuration bits. If I write the
equivalent in assembly code it seems to generate the correct configuration
bits.
This is a little bit annoying, but I have been changing the codes manually
in the .hex file using piklab in order to overcome the problem. I decided to
comment now because I am starting to suspect this could be related to other
problems I am having with the .hex recorded into the device differing its
behavior from the .cod tested in gpsim.
The code:
-=-=-=-=-=-
#include <pic18fregs.h>
typedef unsigned int word;
word at __CONFIG1H CONFIG1H = 0x01;
// _OSC_XT_1H & _FCMEN_OFF_1H & _IESO_OFF_1H;
word at __CONFIG2L CONFIG2L = 0x0c;
// _PUT_ON_2L & _BODEN_OFF_2L & _BODENV_2_0V_2L;
word at __CONFIG2H CONFIG2H = 0x1e;
// _WDT_DISABLED_CONTROLLED_2H & _WDTPS_1_32768_2H;
word at __CONFIG3H CONFIG3H = 0x80;
// _MCLRE_MCLR_enabled_RA5_input_dis_3H;
word at __CONFIG4L CONFIG4L = 0x01;
// _STVR_ON_4L & _LVP_OFF_4L;
word at __CONFIG5L CONFIG5L = 0x03;
// _CP_0_OFF_5L & _CP_1_OFF_5L;
word at __CONFIG5H CONFIG5H = 0xc0;
// _CPB_OFF_5H & _CPD_OFF_5H;
word at __CONFIG6L CONFIG6L = 0x03;
// _WRT_0_OFF_6L & _WRT_1_OFF_6L;
word at __CONFIG6H CONFIG6H = 0xe0;
// _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H;
word at __CONFIG7L CONFIG7L = 0x03;
// _EBTR_0_OFF_7L & _EBTR_1_OFF_7L;
word at __CONFIG7H CONFIG7H = 0x40;
// _EBTRB_OFF_7H;
void main(void)
{
}
The generated configuration bits as read in piklab are:
CONFIG1H = 0xCF;
CONFIG2L = 0x0F;
CONFIG2H = 0x1F;
CONFIG3H = 0x80;
CONFIG4L = 0x85;
CONFIG5L = 0x03;
CONFIG5H = 0xC0;
CONFIG6L = 0x03;
CONFIG6H = 0xE0;
CONFIG7L = 0x03;
CONFIG7H = 0x40;
To compile I used the exact command line bellow:
sdcc -mpic16 -p18F1220 -Wl,-m config-bug.c
The tools I used are:
piklab 0.12.2
gpasm-0.13.3 beta
sdcc 2.6.4 #4576
The assembly code that worked looks like this:
PROCESSOR PIC18F1220
#INCLUDE <P18F1220.INC>
__CONFIG _CONFIG1H, _IESO_OFF_1H & _FSCM_OFF_1H & _XT_OSC_1H
__CONFIG _CONFIG2L, _PWRT_ON_2L & _BOR_OFF_2L & _BORV_20_2L
__CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_32K_2H
__CONFIG _CONFIG3H, _MCLRE_ON_3H
__CONFIG _CONFIG4L, _DEBUG_ON_4L & _LVP_OFF_4L & _STVR_ON_4L
__CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L
__CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
__CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L
__CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
__CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L
__CONFIG _CONFIG7H, _EBTRB_OFF_7H
ORG 0
BRA START
(...)
Any idea why?
Regards,
Guerra
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
