• AVR Freaks

Hot!Hv2 vs Hv3 (bug, feature or ??)

Author
BillP
Super Member
  • Total Posts : 303
  • Reward points : 0
  • Joined: 2014/09/28 07:53:35
  • Location: CA
  • Status: offline
2019/05/12 11:00:36 (permalink)
0

Hv2 vs Hv3 (bug, feature or ??)

Note: I thought I posted this last week.
 
I am learning Hv3 by starting a new project from scratch.  I added the basic elements DFP, System and Core.  In the Core config I chose only the first three (generate files, enable system interrupts, and enable system ports.  When I tried to compile the generated code, it failed because the osal.h file was missing. Apparently, you must check the Enable OSAL box for every project, so why is the check mark optional?

Next, I needed a timer.  In Hv2, this was added in the Framework by choosing a driver and a system service and a specific timer.  In Hv3, there is a new feature to use the core timer (nice).  I added the CORE TIMER component and in the config I chose Enable Interrupt mode AND generate periodic interrupt.  WRONG!  This caused the compile to fail because some of the CORETIMER initialization items were missing.  You must uncheck the generate Periodic interrupt if you want the CORE TIMER to compile.  Unfortunately, the program does not run as described in the documentation.
 
I dug deeper and found a bug in the ftl files that generate the coretimer.c and .h files. 
 
This is the test for both the .h.ftl and .c.ftl files that uses the input from the config screen. Both files need to be fixed.
<#if CORE_TIMER_INTERRUPT_MODE == true && CORE_TIMER_PERIODIC_INTERRUPT == true>
 
In the header file (plib_coretimer.h.ftl) somewhere after the test, add the following two lines to identify the prototypes:
    <#lt>uint32_t CORETIMER_CounterGet();
    <#lt>void CORETIMER_CompareSet(uint32_t compare);

In the source file (plib_coretimer.c.ftl) somewhere after the test, add the following two routines:
    <#lt>void CORETIMER_CompareSet ( uint32_t compare )
    <#lt>{
    <#lt>    _CP0_SET_COMPARE(compare);
    <#lt>}

    <#lt>uint32_t CORETIMER_CounterGet ( void )
    <#lt>{
    <#lt>    uint32_t count;
    <#lt>    count = _CP0_GET_COUNT();
    <#lt>    return count;
    <#lt>}

Note:  The documentation on the new CORE TIMER feature is better than the usual Hv2 docs.  I hope Microchip continues to improve the documentation for Hv3.

That's enough for now but I hope others will post places where the differences between Hv2 and Hv3 can be problematic.


 
#1

7 Replies Related Threads

    arpananand
    Super Member
    • Total Posts : 396
    • Reward points : 0
    • Joined: 2009/11/18 04:35:42
    • Location: 0
    • Status: offline
    Re: Hv2 vs Hv3 (bug, feature or ??) 2019/05/13 22:58:46 (permalink)
    0
    @BillP
    which version of Harmony 3 are you using? can you please tell exact steps to reproduce OSAL issue?
     
    regarding coretimer issue, couple of APIs which you have mentioned, are not supported for "periodic interrupt" mode. same has been documented in remarks section of those APIs in Harmony doc.
     
     
    #2
    BillP
    Super Member
    • Total Posts : 303
    • Reward points : 0
    • Joined: 2014/09/28 07:53:35
    • Location: CA
    • Status: offline
    Re: Hv2 vs Hv3 (bug, feature or ??) 2019/05/14 07:58:35 (permalink)
    0
    @arpananand (I tried to send this as a PM but it didn't go through so I am posting it here)

    @BillP
    which version of Harmony 3 are you using? can you please tell exact steps to reproduce OSAL issue?

    3.3.0.1.  The steps are:
    • start a new project 
    • add the basic elements DFP, System and Core 
    • In the Core config choose only the first three (generate files, enable system interrupts, and enable system ports. 
    • Compile the generated code (it will fail because the osal.h file is missing).
    regarding coretimer issue, couple of APIs which you have mentioned, are not supported for "periodic interrupt" mode. same has been documented in remarks section of those APIs in Harmony doc.

    Where in the Harmony docs?  A periodic timer needs a callback, otherwise what is its purpose?  All I am pointing out is that the current generated code seems to be missing something.  I made changes to the .ftl files and it works (at least for how I think the periodic timer should work).  If that is not how Microchip intended, then let me (and the forum) know.

    Thanks for checking this out. 

    BTW - I have another "bug" in the dual CDC comm port generated code.  I am still working on how to fix it before I post anything.
     
    #3
    arpananand
    Super Member
    • Total Posts : 396
    • Reward points : 0
    • Joined: 2009/11/18 04:35:42
    • Location: 0
    • Status: offline
    Re: Hv2 vs Hv3 (bug, feature or ??) 2019/05/14 20:54:42 (permalink)
    0
    tell me the device name for which you have created the project.
    also, show screenshot of your MHC "project graph" and "configuration options" windows (highlighting "core" module).
     
    Harmony doc can be found in "csp/doc" folder.
     
    why do you need "CORETIMER_CompareSet" and "CORETIMER_CounterGet" APIs for callback in periodic interrupt mode? there is already an API to register a callback: "CORETIMER_CallbackSet" and API to start the timer: "CORETIMER_Start"
     
    these should be enough for you in periodic callback mode.
     
     
     
     
    #4
    BillP
    Super Member
    • Total Posts : 303
    • Reward points : 0
    • Joined: 2014/09/28 07:53:35
    • Location: CA
    • Status: offline
    Re: Hv2 vs Hv3 (bug, feature or ??) 2019/05/15 13:41:28 (permalink)
    0
    I'm not sure what you mean by device name?  I am using the PIC32MZ EF Starter Kit. 
     
    Attached are 4 screen shots showing how I go to the error.  All of the source code is Harmony-generated - I have not added my own application code.

    Attached Image(s)

    #5
    arpananand
    Super Member
    • Total Posts : 396
    • Reward points : 0
    • Joined: 2009/11/18 04:35:42
    • Location: 0
    • Status: offline
    Re: Hv2 vs Hv3 (bug, feature or ??) 2019/05/15 21:21:29 (permalink)
    5 (1)
    i am able to reproduce the coretimer issue you have been reporting. earlier i thought you are using coretimer alone i.e. without sys_time, thats why i was not able to reproduce the issue.
     
    when you use sys_time, you should not be configuring coretimer module manually. sys_time will configure coretimer module automatically if it has to. in this case, sys_time module needs to use coretimer without periodic interrupt. if user manually enables periodic interrupt in coretimer, then sys_time won't be able to undo it as user always has highest priority.
     
    we will later add some sort of warning/restriction to avoid such mistakes by user.

    coming to osal issue, i am still not able to reproduce it. if i don't have any modules on my project graph except core, dfp and system, then osal option need not be checked and code should compile. if u can show the screenshot of build error for osal, it will be helpful.
     
    post edited by arpananand - 2019/05/15 21:23:43
    #6
    vgandhi
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2016/10/24 21:28:35
    • Location: 0
    • Status: offline
    Re: Hv2 vs Hv3 (bug, feature or ??) 2019/05/15 21:45:52 (permalink)
    5 (1)
    The timer system service is based on a tick-less implementation and requires timer peripheral library (in this case, core timer) to generate compare interrupt (and not the periodic interrupts). The compare period of the timer PLIB is automatically controlled by the timer system service.
     
     
    Further, the timer system service automatically configures the core-timer to the appropriate mode, when the timer system service is connected to the core-timer PLIB. However, if the user changes the core-timer configuration (either before or after connecting the timer system service), then the user settings will take precedence. In this case the timer system service may not work as expected.
     
     
    In a nutshell, simply connecting the timer system service with the core-timer PLIB (without any configuration changes to the core-timer PLIB configuration) should work.
     
    Also, for PIC32MZ, you can refer to the demo application code available under core/apps/system/time/sys_time_multiclient/firmware/pic32mz_ef_sk.X
     
    Further information on the Time System Service is available in the harmony help documentation available under core/doc
    post edited by vgandhi - 2019/05/15 21:49:30
    #7
    BillP
    Super Member
    • Total Posts : 303
    • Reward points : 0
    • Joined: 2014/09/28 07:53:35
    • Location: CA
    • Status: offline
    Re: Hv2 vs Hv3 (bug, feature or ??) 2019/05/16 09:50:10 (permalink)
    0
    @vgandhi and @arpananand

    Thank you for looking at this.  What I was trying to do was use the Coretimer the same way  I used one of the on-chip timers in H2.  Unless there is some reason why this cannot or should not be done, IMHO, using the coretimer is simpler to implement than the on-chip timer (see below).
    The timer system service is based on a tick-less implementation and requires timer peripheral library (in this case, core timer) to generate compare interrupt (and not the periodic interrupts). The compare period of the timer PLIB is automatically controlled by the timer system service.

    In a nutshell, simply connecting the timer system service with the core-timer PLIB (without any configuration changes to the core-timer PLIB configuration) should work.

    It does, but not how I want to use it.

    Here is how I implemented a 1ms timer/interrupt in H2.06.

    I configured TMR_ID_2 for a 1ms interrupt.
    /*** Timer Driver Configuration ***/
    #define DRV_TMR_INTERRUPT_MODE true
    #define DRV_TMR_INSTANCES_NUMBER 1
    #define DRV_TMR_CLIENTS_NUMBER 1

    /*** Timer Driver 0 Configuration ***/
    #define DRV_TMR_PERIPHERAL_ID_IDX0 TMR_ID_2
    #define DRV_TMR_INTERRUPT_SOURCE_IDX0 INT_SOURCE_TIMER_2
    #define DRV_TMR_INTERRUPT_VECTOR_IDX0 INT_VECTOR_T2
    #define DRV_TMR_ISR_VECTOR_IDX0 _TIMER_2_VECTOR
    #define DRV_TMR_INTERRUPT_PRIORITY_IDX0 INT_PRIORITY_LEVEL1
    #define DRV_TMR_INTERRUPT_SUB_PRIORITY_IDX0 INT_SUBPRIORITY_LEVEL0
    #define DRV_TMR_CLOCK_SOURCE_IDX0 DRV_TMR_CLKSOURCE_INTERNAL
    #define DRV_TMR_PRESCALE_IDX0 TMR_PRESCALE_VALUE_8
    #define DRV_TMR_OPERATION_MODE_IDX0 DRV_TMR_OPERATION_MODE_16_BIT
    #define DRV_TMR_ASYNC_WRITE_ENABLE_IDX0 false
    #define DRV_TMR_POWER_STATE_IDX0 SYS_MODULE_POWER_RUN_FULL

    Here is the a snippet of source code from app.c I used in H2.
    /* TODO: Add any necessary callback functions. */
    void tmrcallback(uintptr_t context, uint32_t currtick);
    void tmrcallback(uintptr_t context, uint32_t currtick)
    {
        /* this will only happen after the timer is started */
        appData.appstate = APP_STATE_EVENT;
    }

            case APP_STATE_INIT:
            {
                bool appInitialized = true;
                if (appInitialized)
                {
                    appData.sysTmrHandle = SYS_TMR_CallbackPeriodic(PERIODMS,1,tmrcallback);
                    appData.appstate = APP_STATE_IDLE;
                }
                break;

    To duplicate this functionality in H3, here is the configuration and source code AFTER I modified the .ftl files I posted in the original post.
    /* TIME System Service Configuration Options */
    #define SYS_TIME_INDEX_0 0
    #define SYS_TIME_MAX_TIMERS 5
    #define SYS_TIME_HW_COUNTER_WIDTH 32
    #define SYS_TIME_HW_COUNTER_PERIOD 4294967295U
    #define SYS_TIME_HW_COUNTER_HALF_PERIOD (SYS_TIME_HW_COUNTER_PERIOD>>1)
    #define SYS_TIME_CPU_CLOCK_FREQUENCY 200000000
    #define SYS_TIME_COMPARE_UPDATE_EXECUTION_CYCLES (620)

    /* TODO: Add any necessary callback functions. */
    void CORETIMER_Callback_Fn(uintptr_t context);
    void CORETIMER_Callback_Fn(uintptr_t context)
    {
        /* this will only happen after the timer is started */
        appData.appstate = APP_STATE_EVENT;
    }


            case APP_STATE_INIT:
            {
                bool appInitialized = true;
                if (appInitialized)
                {
                    // Register Callback
                    CORETIMER_CallbackSet(CORETIMER_Callback_Fn, NULL);
                    CORETIMER_Start();
                    appData.appstate = APP_STATE_IDLE;
                }
                break;


    when you use sys_time, you should not be configuring coretimer module manually.

    Why?
    we will later add some sort of warning/restriction to avoid such mistakes by user.

    Was this really a mistake?
    coming to the osal issue, i am still not able to reproduce it

    Ignore this one.  I must have dragged one of the components to the graph screen and then turned off the osal option manually.  Sorry.  Even if there is some path to get this error, it is obvious and easily fixed.
     
     
    #8
    Jump to:
    © 2019 APG vNext Commercial Version 4.5