Subject:
Re: PIC18F47J53
From:
Luis de Arquer ####@####.####
Date:
17 Aug 2013 16:47:20 -0000
Message-Id: <CAD_DGvk-ibU0v21dUYCQAyoN1RCdt2i_S-V+tBrjLM8xMTkvRw@mail.gmail.com>
Mmmmm, sorry for the spam, but I think I have found one of the keys...
Making XINST = OFF seems to fix the loop issue! I'll keep on
investingating it, but it has definitely made a change.
XINST was enabled by default, as specified in the datasheet. I didn't
thought it was that important... :S
Regards,
Luis
On Sat, Aug 17, 2013 at 5:17 PM, Luis de Arquer ####@####.#### wrote:
> On Tue, Aug 13, 2013 at 9:28 PM, Luis de Arquer ####@####.#### wrote:
>> I think I am giving up on this one.
>>
>
>
> Well... not really, still playing around.
>
> I did some code from scratch with gpasm, and everything seems to be
> fine. I will keep on trying to find what's wrong with my crt0i.c
>
> Also, Pickit2 seems fine to me with the 18f47j53. I had a look at the
> raw hex files, flashed them, read them back, and everything looked OK.
> I guess that's not a 100% guarantee, since I am using the same
> "under-test" programmer to read back, but everything runs normally...
>
> It gave some errors with code assembled with mpasm though. The reason
> was, in case someone is interested, that if any of the config words
> was not specified in the code (as it was the case, leaving them as
> default), mpasm didn't specify those config words in the .hex file
> either. On the other hand, pk2cmd seems to assume that, if some word
> is not specified in the hex file, it has to be flashed as 0xFFFF.
> However, some of these config words have some bits unimplemented, and
> it is the case that two of those unimplemented bits in the 18f47j53
> read always as '0'. So pk2cmd was writing 0xFFFF and reading 0xFBFF
> throwing this error.
>
> Fortunately, it looks like gpasm explicitely declares all the config
> words in the .hex file :)
>
> Regards,
>
> Luis
