> The code:
> -=-=-=-=-=-
> #include <pic18fregs.h>
> typedef unsigned int word;
> Any idea why?

Well, this is bad... CONFIG 'words' are `unsigned char' (8 bit) rather
than `unsigned int' (16 bit). This explains part of the problems.

Oops, it seems I did a big mistake. Unfortunately this cannot completely explain the problems I am having since I have not been using this configuration bits from SDCC, but rather configuring by hand directly in the .hex using piklab interface.

On my box I currently seem not to be able to set CONFIG bits correctly
from within SDCC: the gemerated .asm code looks not that bad (creating
absolute sections with initialized data at the config word locations),
but gpasm divides their addresses by two... So maybe using
        unsigned char __at(__CONFIG2L<<1) conf2l = ...;
instead of
        unsigned char __at(__CONFIG2L) conf2l = ...;
helps for now, but this needs more looking into and possibly a bug
report to the gputils team (if confirmed).

Oh, so it might be a problem with gpasm? I just do not understand how the .asm code fragment I showed in the first email of this thread worked fine then... I will try to have another look, but I have the feeling the first pointer assignment problem could be related to all this somehow...


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
Sdcc-user mailing list

Rodrigo da Silva Guerra
PhD Student

Department of Adaptive Machine Systems
Graduate School of Engineering
Osaka University - Japan