Subject:
Re: PIC18F47J53
From:
Luis de Arquer ####@####.####
Date:
12 Aug 2013 21:21:55 -0000
Message-Id: <CAD_DGv=_QyO_bVR4zJ1LWr6hjRt4SG8uwLSfxnnt3PmmVnxzsw@mail.gmail.com>
As an update, I have disabled the two-speed start just in case, but no
change. I have also protected the configuration bits for read-only, in
case some initialization code changed something (i doubt it anyway).
But still the same :(
How can possibly the clock speed change every time? And why doesn't it
happen with crt0.c? crt0i.c reads the program memory, is that a very
power-demanding task? I haven't got any ceramic 10uF capacitor for
Vddcore, so I've put a 10uF electrolytic + 0.22 uF ceramic, that's the
only reason I can think of. However, the Vddcore looks fine on the
scope...
Maybe it's time to replace the PIC... ;)
Luis
On Mon, Aug 12, 2013 at 9:09 PM, Luis de Arquer ####@####.#### wrote:
> Thanks all of you for your help.
>
> That was indeed the reason, I had completely overlooked the analog config :S
>
> That's the good news, the bad news for me is that I had some hope that
> fixing this would point me to the right direction to fix the
> apparently more-complicated problems I was having.
>
> I'll put them here as well in case you guys are so kind to keep giving
> me a hand.
>
> Problem number 1 is surely a C issue, which is the sleep function I made:
>
> ****************************
>
> typedef unsigned char byte;
>
> void sleep_a_while(byte c) /* A */
> {
> byte i,j; /* B */
>
> for(i=0; i<200; i++)
> for(j=0; j<c; j++) ;
> }
>
>
> **************************
>
> Changing "byte" for "int" in any of those lines changes the timing. It
> makes the sleep time not only different -which makes sense since int
> is translated to int16 apparently, with its overhead-, but independent
> on c (the input parameter ! ).
> Probably this is something to discuss in the SDCC maillist anyway,
> though the asm code looked fine. I can post it if you think it's
> worth, but I'm far more worried about...
>
> 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
>
>
>
> On Mon, Aug 12, 2013 at 7:13 PM, KHMan ####@####.#### wrote:
>> On 8/13/2013 1:52 AM, Luis de Arquer wrote:
>>>
>>> Hi Bob,
>>>
>>> Thanks for the info, since that was something I didn't know anyway.
>>>
>>> As you say, that may not be the problem after all. The 'sleep_a_while'
>>> function that is called in between is defined as (in C code)
>>>
>>> void sleep_a_while(byte c)
>>> {
>>> byte i,j;
>>>
>>> for(i=0; i<200; i++)
>>> for(j=0; j<c; j++) ;
>>> }
>>>
>>> so surely it has enough time to settle.
>>>
>>> I have seen some examples around using lots of config words for the
>>> PIC, while I am only using these:
>>>
>>> CONFIG OSC=INTOSC,WDTEN=OFF
>>>
>>> I have read all of the other config words and thought I don't need any
>>> more, but maybe I am missing shtg?
>>
>>
>> Not much else to eliminate... analog config, open drain settings, etc., but
>> your first example works.
>>
>> What happens if you toggle LATB instead? Then the datapath would not need to
>> sample PORTB. Or toggle the whole byte?
>>
>>> On Mon, Aug 12, 2013 at 6:27 PM, Bob Jacobsen wrote:
>>>>
>>>> On Aug 12, 2013, at 9:58 AM, Luis de Arquer wrote:
>>>> [snipped all]
>>
>>
>> --
>> Cheers,
>> Kein-Hong Man (esq.)
>> Kuala Lumpur, Malaysia
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>>
