gnupic: Thread: PIC18F47J53

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

Hi Luis, I'm not familiar with the sdd linker but on the microchip 
linker the files that end with an 'i' do reserve some resources for an 
external debugger like the ICD2, ICD3, pickit3, etc.

If that is also the case for the sdcc linker and if you are not using a 
debugger as a debugger (you are using it only as a programmer), then you 
shouldn't use the i files.

Regards,

-- 
Mauricio Giovagnini (Maunix)
Sitio Web: www.maunix.com.ar



El 12/08/2013 05:09 p.m., Luis de Arquer escribió:
> Problem 2:
>
> This is the scary one. In the gplink line, if I change "crt0.o" by
> "crt0i.o", the clock settings go random on startup. Again, I'll
> probably post it in the sdcc maillist, but the crt0i.c is almost
> entirely written in asm (it comes bundled with sdcc in
> "device/lib/pic16/startup/", but I can post it here if you want).
> So basically, the blink frequency is different with every power on
> reset; sometimes visible, sometimes you need the oscilloscope.
> Obviously I am not asking for anyone to dig into crt0i.c (it seems to
> be the same basic stack initialization than crt0.c plus data
> initialization (.cinit), reading stuff from program memory and copying
> to RAM). The question is, what sort of thing could cause a random
> clock setting with every hard reset? -soft reset not tested yet.
>
> It has to be electrical, hasn't it?
>
> Regards,
>
> Luis
>

Marko Kohtala writes ("Re: PIC18F47J53"):
> It is best using LATB for output.

Yes.

> Check your ADCON1. The pin is at reset analog input. PORTB reads digital
> input even while you have TRISB bit cleared. Reading digital input on
> analog input always reads 0 and therefore BTG always writes 1.

Using LATB avoids all of this, because you base your new state on the
last state you asked for without doing any kind of GPIO input.

Ian.