gnupic: Thread: PIC18F47J53

Gents,

I am using sdcc + gputils on a home-made board, with a PIC18F47J53
(44-pin TQFP microcontroller, and I am coming accross a few issues.
The fact that there are more than one issue, makes me think that maybe
something electrical is wrong.

However, just in case someone has experienced this before, I am
posting the most obvious of the problems.

I have tried a simple program blinking an LED. It does work, if I use
the instructions

PORTB &= 0x08
PORTB |= 0x08

for toggling the LED (see asm translation below).
However if I use

PORTB ^= 0x08

which translates to a BTG (bit toggle) instruction, it won't blink at
all -it will light the LED up though, but no blinking can be seen even
with the oscilloscope.

It looks to me that the C -> asm compilation is OK.

I know it sounds a bit ridiculous, and I think the chances are 50/50
that I am either making a very obvious error on the software side, or
there is some electronic issue on the board. However, after hours
messing around I couldn't find an explanation. Maybe the BTG
instruction is not available in the j-series, or coded in a different
way?

Below is the and/or-version asm code (the one that works), the
BTG-version asm code, and the gpasm/gplink command line.

BTW, has anyone succesfully used this microcontroller with gputils before?

Regards,

Luis de Arquer


*********************  AND/OR version (works OK!)
******************************

; I code from now on!
; ; Starting pCode block
S_test__main    code
_main:
;    .line    26; test.c    TRISB = ~0x08;
    MOVLW    0xf7
    MOVWF    _TRISB
;    .line    27; test.c    PORTB = PORTB | 0x08;
    BSF    _PORTB, 3
_00132_DS_:
;    .line    31; test.c    sleep_a_while(0x20);
    MOVLW    0x20
    MOVWF    POSTDEC1
    CALL    _sleep_a_while
    MOVF    POSTINC1, F
;    .line    33; test.c    PORTB &= ~0x08;
    MOVF    _PORTB, W
    MOVWF    r0x00
    MOVLW    0xf7
    ANDWF    r0x00, W
    MOVWF    _PORTB
;    .line    35; test.c    sleep_a_while(0x20);
    MOVLW    0x20
    MOVWF    POSTDEC1
    CALL    _sleep_a_while
    MOVF    POSTINC1, F
;    .line    37; test.c    PORTB |= 0x08;
    BSF    _PORTB, 3
    BRA    _00132_DS_
    RETURN



********************* BTG version -not working :( ************************

; I code from now on!
; ; Starting pCode block
S_test__main    code
_main:
;    .line    26; test.c    TRISB = ~0x08;
    MOVLW    0xf7
    MOVWF    _TRISB
;    .line    27; test.c    PORTB = PORTB | 0x08;
    BSF    _PORTB, 3
_00132_DS_:
;    .line    31; test.c    sleep_a_while(0x20);
    MOVLW    0x20
    MOVWF    POSTDEC1
    CALL    _sleep_a_while
    MOVF    POSTINC1, F
;    .line    33; test.c    PORTB ^= 0x08;
    BTG    _PORTB, 3
;    .line    35; test.c    sleep_a_while(0x20);
    MOVLW    0x20
    MOVWF    POSTDEC1
    CALL    _sleep_a_while
    MOVF    POSTINC1, F
;    .line    37; test.c    PORTB ^= 0x08;
    BTG    _PORTB, 3
    BRA    _00132_DS_
    RETURN



********************* Command line       ******************************

+ /usr/local/bin/gpasm -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o
test.o -c test.asm
+ /usr/local/bin/gplink -I/usr/local/bin/../share/sdcc/lib/pic16
-I/usr/local/share/sdcc/lib/pic16
-I/usr/local/bin/../share/sdcc/non-free/lib/pic16
-I/usr/local/share/sdcc/non-free/lib/pic16   -w -r -o test test.o
crt0.o libdev18f47j53.lib libsdcc.lib libc18f.lib
message: using default linker script
"/usr/local/share/gputils/lkr/18f47j53_g.lkr"

On Aug 12, 2013, at 9:58 AM, Luis de Arquer ####@####.#### wrote:

> 
> I have tried a simple program blinking an LED. It does work, if I use
> the instructions
> 
> PORTB &= 0x08
> PORTB |= 0x08
> 
> for toggling the LED (see asm translation below).
> However if I use
> 
> PORTB ^= 0x08
> 
> which translates to a BTG (bit toggle) instruction, it won't blink at
> all -it will light the LED up though, but no blinking can be seen even
> with the oscilloscope.


Perhaps some hints here:

http://www.xargs.com/pic/c-faq.html#rmw

but that doesn't seem to fit your timing.

Bob
--
Bob Jacobsen, LBNL Physics Division
####@####.#### +1-510-486-7355 AIM, Skype JacobsenRG

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?

Regards,

Luis

Luis

On Mon, Aug 12, 2013 at 6:27 PM, Bob Jacobsen ####@####.#### wrote:
>
> On Aug 12, 2013, at 9:58 AM, Luis de Arquer ####@####.#### wrote:
>
>>
>> I have tried a simple program blinking an LED. It does work, if I use
>> the instructions
>>
>> PORTB &= 0x08
>> PORTB |= 0x08
>>
>> for toggling the LED (see asm translation below).
>> However if I use
>>
>> PORTB ^= 0x08
>>
>> which translates to a BTG (bit toggle) instruction, it won't blink at
>> all -it will light the LED up though, but no blinking can be seen even
>> with the oscilloscope.
>
>
> Perhaps some hints here:
>
> http://www.xargs.com/pic/c-faq.html#rmw
>
> but that doesn't seem to fit your timing.
>
> Bob
> --
> Bob Jacobsen, LBNL Physics Division
> ####@####.#### +1-510-486-7355 AIM, Skype JacobsenRG
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

Hi.

It is best using LATB for output.

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.

Marko


2013/8/12 Luis de Arquer ####@####.####

> 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?
>
> Regards,
>
> Luis
>
> Luis
>
> On Mon, Aug 12, 2013 at 6:27 PM, Bob Jacobsen ####@####.####
> wrote:
> >
> > On Aug 12, 2013, at 9:58 AM, Luis de Arquer ####@####.####
> wrote:
> >
> >>
> >> I have tried a simple program blinking an LED. It does work, if I use
> >> the instructions
> >>
> >> PORTB &= 0x08
> >> PORTB |= 0x08
> >>
> >> for toggling the LED (see asm translation below).
> >> However if I use
> >>
> >> PORTB ^= 0x08
> >>
> >> which translates to a BTG (bit toggle) instruction, it won't blink at
> >> all -it will light the LED up though, but no blinking can be seen even
> >> with the oscilloscope.
> >
> >
> > Perhaps some hints here:
> >
> > http://www.xargs.com/pic/c-faq.html#rmw
> >
> > but that doesn't seem to fit your timing.
> >
> > Bob
> > --
> > Bob Jacobsen, LBNL Physics Division
> > ####@####.#### +1-510-486-7355 AIM, Skype JacobsenRG
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>

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

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: ####@####.####
>

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: ####@####.####
>>

On Aug 12, 2013, at 1:09 PM, Luis de Arquer ####@####.#### wrote:

> 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 ! ).


Do you mean if you change (A) but not (B) or vice-versa?

I'd check the assembler code to see what's happening to the upper byte of the int values.  If it's being left unchanged, all sorts of interesting things can happen, particularly if you call sleep-a-while with a value greater than 127.

Bob
--
Bob Jacobsen, LBNL Physics Division
####@####.#### +1-510-486-7355 AIM, Skype JacobsenRG

I think I am giving up on this one.

I have put all the right SMD capacitors as close as I could, including
a 10uF ceramic for vddcore, but still the same issue.

I am using pickit2 for this pic (18f47j53), and although I found a
.dat file which supports it, I couldn't find anywhere in the microchip
website saying it is supported really... so that could be the source
of the grief.

Thank you all anyway :)

On Mon, Aug 12, 2013 at 10:54 PM, Bob Jacobsen ####@####.#### wrote:
>
> On Aug 12, 2013, at 1:09 PM, Luis de Arquer ####@####.#### wrote:
>
>> 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 ! ).
>
>
> Do you mean if you change (A) but not (B) or vice-versa?
>
> I'd check the assembler code to see what's happening to the upper byte of the int values.  If it's being left unchanged, all sorts of interesting things can happen, particularly if you call sleep-a-while with a value greater than 127.
>
> Bob
> --
> Bob Jacobsen, LBNL Physics Division
> ####@####.#### +1-510-486-7355 AIM, Skype JacobsenRG
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

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