• AVR Freaks

Hot!__delay_ms() too fast after bootloader

Page: 12 > Showing page 1 of 2
Author
EduardoTensator
Starting Member
  • Total Posts : 48
  • Reward points : 0
  • Joined: 2020/12/18 08:21:08
  • Location: 0
  • Status: offline
2021/01/12 02:04:41 (permalink)
0

__delay_ms() too fast after bootloader

Hi

I'm running MPLAB X 5.45 on Windows 10, with XC8 compiler 2.31, PICkit3 developing on a PIC18F46K22
 
I have made a simple bootloader. When this bootloader starts and passes the the control to the application it seems that the function __delay_ms() provided in pic18.h does not execute in the same timing. It seems the delay is much smaller.
 
Any ideas what this could be?
by the way, the configuration bits are the same in the bootloader and in the application.
Is it possible that this _delayms() function uses TMR0? I'm not including/initialising TMR0 in the bootloader only in the application.
 
thanks
post edited by EduardoTensator - 2021/01/12 02:15:29
#1

25 Replies Related Threads

    ric
    Super Member
    • Total Posts : 29435
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 02:23:00 (permalink)
    +2 (2)
    __delay_ms() is a macro that requires a correct definition for "_XTAL_FREQ" in your source files.
    What value is it defined as in the bootloader?
    In the application?
     
    (No, it does NOT use any hardware timers)
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 02:31:08 (permalink)
    0
    the _XTAL_FREQ is defined in device_config.h as
     
    #define _XTAL_FREQ 64000000
     
    and it has the same value in the bootloader and in the application.
    What other things could explain the different behaviour?
     
    thanks
    post edited by EduardoTensator - 2021/01/12 02:41:55
    #3
    ric
    Super Member
    • Total Posts : 29435
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 02:41:37 (permalink)
    +2 (2)
    Something is not as you think it is.
    I don't know if it's pulling in a different header file, or what from the limited information you are supplying.
    Either the PIC is not running at the speed you think it is, or a different value for _XTAL_FREQ is being used for some reason.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #4
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 02:46:52 (permalink)
    0
    When I search for _XTAL_FREQ  it only appears on device_config.h file and it's assigned to 64000000 (64MHz).
    Both bootloader and application use the same definition...
     
    Is there anyway of slowing down the pic that the application could be used and it's not in place in the bootloader? Some prescaler/divider/whatever?
    ARMs microcontrollers have this capability which sometimes makes very difficult to understand at what speed the processor is running...
    #5
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 03:14:20 (permalink)
    0
    Could someone explain why microchip defined on the pic18.h file come up with definitions that use floating point?
    Don't see the point... :)
     
    #define __delay_us(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
    #define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
     

    _XTAL_FREQ/4000000.0 with _XTAL_FREQ equal to 64000000 is 16.
    _XTAL_FREQ/4000.0 with _XTAL_FREQ equal to 64000000 is 16000.
     
    Is there here any hidden long time forgotten wisdom?
    Maybe it makes sense in other micros...
     
    Will this bring the big floating point library into play with some Ks?
    I would assume that the floating point operations in a PIC18 are sloooooow. Would this be the case?
     
    thanks
    post edited by EduardoTensator - 2021/01/12 03:19:13
    #6
    ric
    Super Member
    • Total Posts : 29435
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 03:16:42 (permalink)
    +1 (1)
    That chip has a lot of control of the internal oscillator, all documented in chapter "2.0 OSCILLATOR MODULE (WITH FAIL-SAFE CLOCK MONITOR)"
    If the PLL is not enabled, then you will only be running at 16MHz.
    Again, I cannot debug that for you as I don't have your source files, and yo uhave said very little about how you have set the clock.
     
     
    post edited by ric - 2021/01/12 03:23:10

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #7
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 03:23:56 (permalink)
    0
    thanks, that sounds a good clue! :)
    #8
    ric
    Super Member
    • Total Posts : 29435
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 03:29:26 (permalink)
    +3 (3)
    EduardoTensator
    Could someone explain why microchip defined on the pic18.h file come up with definitions that use floating point?
    Don't see the point... :)

    All those calculations are done by the preprocessor at compile time (i.e. your PC), NOT the PIC.
    Floating point is done for accuracy. It has NO effect on your PIC.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #9
    Mysil
    Super Member
    • Total Posts : 4062
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 03:36:58 (permalink)
    0
     
    PIC microcontrollers have several different Timing sources, that may be clocked by the Instruction clock frequency, 
    or by various internal frequencies, or by an external clock signal.
    __delay_ms(...)    is just one of the possibilities, and it work by counting instruction clock cycles.
    __delay_ms(...)    giving too short delays in application code, indicate that application code was compiled with _XTAL_FREQ  specified with a lower  frequency.
     
    There are several other possibilities, using one of the Timer modules in hardware,
    that require you to read Datasheet, how to set it up, write code, recompile and link the application.
     
    Another possibility, is to change values in OSCCON  register, to change system clock frequency.
    This may be done in application code.
     
    Be aware that it is possible for the Compiler, to find and use different or additional header files,
    than those visible in MPLAB X.
    Searching for text in MPLAB X 'Find in Project' tool,
    will only search in those files that are part of 'Projects'.
     
        Mysil
    #10
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 05:27:19 (permalink)
    0
    I ran the debugger on the application and on the the bootloader and the code is the same:
     
    void OSCILLATOR_Initialize(void)
    {
        // SCS FOSC; IRCF 16MHz_HFINTOSC; IDLEN disabled;
        OSCCON = 0x70;
        // PRISD enabled; SOSCGO disabled; MFIOSEL disabled;
        OSCCON2 = 0x04;
        // INTSRC disabled; PLLEN enabled; TUN 0;
        OSCTUNE = 0x40;
     
    When the debugger is stopped after initialising I get:
     
    OSCCON   = 7Ch
    OSCCON2 = 87h
    OSCTUNE = 40h
     
    Checking the bits it seems that both firmware are running with the processor at 64MHz...
     
    I don't think the _XTAL_FREQ can be any different 64000000, but I can I be sure that it is?
    Any ideas?
     
     
    #11
    ric
    Super Member
    • Total Posts : 29435
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 05:55:14 (permalink)
    +2 (2)
    Do you have a serial output, or LCD or some other form of output?
    Just output the value with printf() etc.
    How exactly are you testing what delay you are getting?
    Have you tried using the config option to output the instruction clock on a pin so you can measure it directly?
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #12
    oliverb
    Super Member
    • Total Posts : 369
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 06:13:11 (permalink)
    0
    To verify the setting of _XTAL_FREQ could you try adding a message, warning or an "#assert" test.
     
    I'm not familiar with the syntax but I think the syntax would be
    #assert _XTAL_FREQ == 64000000
     
     
    #13
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 06:17:51 (permalink)
    0
    There is no doubt.
    Using the simplest C code
     
    unsigned long freq = _XTAL_FREQ;
     
    one can see in the debugger that freq is 64000000.
    #14
    Mysil
    Super Member
    • Total Posts : 4062
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 07:25:26 (permalink)
    +1 (1)
    Hi,
    There is no doubt.
    Using the simplest C code
        unsigned long freq = _XTAL_FREQ;
    one can see in the debugger that freq is 64000000.

    For this to be correct proof, the above test must be done inside the same function where
        __delay_ms(...);
    is used.
     
        Mysil
    #15
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 07:49:47 (permalink)
    -1 (1)
    a good point although being defined as 
     
    #define __delay_us(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
    #define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
     
    I don't see how can _XTAL_FREQ end up with 2 different values!
     
    Still those floating point operations are making me nervous! :)
    how fast or slow are the floating point operations in PIC18F at 16MHz or something?...
    could it happen that the compiler sees 64000000/4000.0 and just replaces the value by 1600 and no floating point operations are done?
    post edited by EduardoTensator - 2021/01/12 07:51:14
    #16
    oliverb
    Super Member
    • Total Posts : 369
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 08:30:17 (permalink)
    +1 (1)
    That is the whole point, the calculation IS done by the compiler. The division could easily return a fractional value, so integer math wouldn't handle it.
     
    Thinking about this: if the delay was unexpectedly long I'd assume the clock was lower than expected, but as the delay is shorter and the clock is at maximum I doubt the program is actually running faster than it should, so instead I wonder if the calculation is returning a cycle count longer than is allowed and the value is getting silently truncated. The maximum permissable value for your clock appears to be just over 11ms, though I seem to recall using 100ms delays in my own code.
     
    I'd be inclined to try _delay(cycles)  directly and see what happens.
    #17
    MBedder
    Circuit breaker
    • Total Posts : 6947
    • Reward points : 0
    • Joined: 2008/05/30 11:24:01
    • Location: Zelenograd, Russia
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 08:32:15 (permalink)
    +3 (3)
    Are you able to read, or just write? If yes - read post #9, if no - ...
    #18
    EduardoTensator
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2020/12/18 08:21:08
    • Location: 0
    • Status: offline
    Re: __delay_ms() too fast after bootloader 2021/01/12 11:58:45 (permalink)
    -1 (1)
    "Are you able to read, or just write? If yes - read post #9, if no - ... "
     
    Sorry I don't understand what you mean.
    Where can I find post #9?
    #19
    ric
    Super Member
    • Total Posts : 29435
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: __delay_ms() too fast after bootloader 2021/01/12 12:12:55 (permalink)
    +1 (1)
    EduardoTensator
    "Are you able to read, or just write? If yes - read post #9, if no - ... "
     
    Sorry I don't understand what you mean.
    Where can I find post #9?

    It is the ninth post in this thread. Every post is numbered in the bottom right corner, although you can't see this if you are reading via a smartphone rather than a PC.
    It was my post, telling you that the calculations done using _XTAL_FREQ are done by the compiler at compile time, about four hours before you asked the same question again in post#16.
     
     
    post edited by ric - 2021/01/12 12:22:41

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2021 APG vNext Commercial Version 4.5