This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Hwi warnings with cc2650DK

Other Parts Discussed in Thread: SYSBIOS, CC2650

I use ccs Version: 6.1.0.00104 and install TI-RTOS for Simplelink  (tirtos_simplelink_2_14_01_19) from App Center,

and then use the example of pinInterrupt.

Hwi instance is added through the GUI of cfg.

The followings are then appended to pinInterrupt.cfg

var halHwi0Params = new halHwi.Params();

halHwi0Params.instance.name = "halHwi0";

halHwi0Params.priority = 1;

halHwi0Params.maskSetting = xdc.module("ti.sysbios.interfaces.IHwi").MaskingOption_ALL;

halHwi0Params.enableInt = true;

Program.global.halHwi0 = halHwi.create(16, "&hwi_isr", halHwi0Params);

 

In the pinInterrupt.c ,  the callback function is disabled by remarking it.

/* Setup callback for button pins */

// if (PIN_registerIntCb(buttonPinHandle, &buttonCallbackFxn) != 0) {

// System_abort("Error registering button callback function");

// }

the following function is added into the pinInterrupt.c for an interrupt call.

void hwi_isr (void)

{....}

 

When compiling the code, there are 73 warnings which are all about the Hwi. the followings are two of them.

#48-D incompatible redefinition of macro "Hwi_clearInterrupt" (declared at line 652 of "C:/ti/tirtos_simplelink_2_14_01_19/products/bios_6_42_02_29/packages/ti/sysbios/hal/Hwi.h") .ccsproject /pinInterrupt_CC2650DK_TI_CC2650F128 line 1289, external location: C:\ti\tirtos_simplelink_2_14_01_19\products\bios_6_42_02_29\packages\ti\sysbios\family\arm\m3\Hwi.h C/C++ Problem

#48-D incompatible redefinition of macro "Hwi_construct" (declared at line 670 of "C:/ti/tirtos_simplelink_2_14_01_19/products/bios_6_42_02_29/packages/ti/sysbios/hal/Hwi.h") .ccsproject /pinInterrupt_CC2650DK_TI_CC2650F128 line 1318, external location: C:\ti\tirtos_simplelink_2_14_01_19\products\bios_6_42_02_29\packages\ti\sysbios\family\arm\m3\Hwi.h C/C++ Problem

When entering the debug mode, I set breakpoint to "ledPinHandle = PIN_open(&ledPinState, ledPinTable);"

and the first code of hwi_isr. Both codes have never been reached.

 

Have I missed out anything to set the Hwi?

 

Regards,  Thomas


 

  • Thomas,

    You can eliminate the warnings by removing this line from pinInterrupt.c:

    #include <xdc/cfg/global.h>

    That line is unnecessary for this example, and when you add a Hwi, the inclusion of this file will cause generation of these warnings.

    Regarding not getting to your breakpoints…  what is happening is that you are attempting to take over the edge detect interrupt with your Hwi.  But this interrupt is already configured for the PIN driver.   Board_initGeneral() calls the PIN_init() function, which does a Hwi_construct() call to use the edge detect interrupt.  Within Hwi_construct() it is seen that this interrupt is already in use (since you added hwi_isr), so a runtime error is thrown.  And because of the way Error handling is configured in the application .cfg file (to reduce memory footprint), the result is the CPU is left spinning in a ROM function to trap the error. I know this result is not at all obvious; I will file an enhancement request to ask for a “master switch” in the example .cfg files, to quickly enable/disable useful Error handling… 

    Regards,
    Scott

  • Scott,

    After remarking the "#include <xdc/cfg/global.h>" , and the warnings are gone. thanks.

    I try to remark the Hwi related code in PIN_init(), but it still cannot reach the breakpoint.

    Regards,
    Thomas
  • Thomas,

    After you modified PIN_init() did you rebuild the PIN driver?  If not, there are instructions for rebuilding in Chapter 9 of the TI-RTOS User’s Guide (in the “docs” subdirectory of the TI-RTOS installation).

    Are you doing these Hwi modifications just for temporary experimentation purposes?  If no, is there some reason you don’t want to use the PIN driver?

    Thanks,
    Scott

  • Scott,

    I try to follow the Chapter 9 to rebuild the pin driver, but still have the same issue.
    However, when using the example of "empty_min", it works well with the hwi_isr() with the samiliar hwi-instance added into the cfg.
    I did not change the code of empty_min, only add in the hwi_isr().

    the header files in empty_min is as follows:

    /* XDCtools Header files */
    #include <xdc/std.h>
    #include <xdc/cfg/global.h>
    #include <xdc/runtime/System.h>

    /* BIOS Header files */
    #include <ti/sysbios/BIOS.h>

    /* TI-RTOS Header files */
    // #include <ti/drivers/I2C.h>
    #include <ti/drivers/PIN.h>
    // #include <ti/drivers/SPI.h>
    // #include <ti/drivers/UART.h>
    // #include <ti/drivers/Watchdog.h>

    /* Board Header files */
    #include "Board.h"

    the header files in pinInterrupt is as follows:
    /* XDCtools Header files */
    #include <xdc/std.h>
    //#include <xdc/cfg/global.h>
    #include <xdc/runtime/System.h>

    /* BIOS Header files */
    #include <ti/sysbios/BIOS.h>
    #include <ti/sysbios/family/arm/cc26xx/Power.h>
    #include <ti/sysbios/family/arm/cc26xx/PowerCC2650.h>

    /* TI-RTOS Header files */
    #include <ti/drivers/PIN.h>
    #include <ti/drivers/pin/PINCC26XX.h>

    /* Example/Board Header files */
    #include "Board.h"

    the first two codes in both pininterrupt.c and empty_min.c are the same.
    I set breakpoint to the second one just after Board_initGeneral() , that is "ledPinHandle = PIN_open(&ledPinState, ledPinTable); "

    in empty_min.c, it breaks but it is not for pininterrupt.c

    I am confused to the setting and the use of header files.


    I use pininterrupt to take some experiment for I/O interrupt. my project is to use I/O interrupt connecting to a sensor.
    when the sensor send out a signal, the cc2650 has to response very fast with the highest priority. after processing, it will then send data through BLE.

    Regards,
    Thomas
  • Thomas,

    After rebuilding the PIN driver did you clean the pinInterrupt example, then rebuild it?  If the change worked for the empty project it should have worked for pinInterrupt too.  Basically I wonder if you created the empty project after already rebuilding the PIN driver (so that is why it works), but the pinInterrupt example wasn’t fully rebuilt after modifying the PIN driver (so that is why it still doesn’t work).  This is just a guess, but maybe it explains the difference.

    I think the bigger question/issue regards you trying to write your own pin handler (using the edge detect interrupt) while also using PIN, which wants to use/manage this same interrupt.  There will probably be many issues if you try doing this.  I’d say that if you don’t want to use PIN then its configuration and the call to PIN_init() should be removed from the application.  But PIN is used by the I2C, LCD, SPI, UART and ADC drivers, so then you wouldn’t be able to use those.

    Have you tried and found that PIN doesn’t meet your speed requirements? 

    Are you ultimately planning to share the edge detect interrupt between your handler and PIN?

    Thanks,
    Scott

  • Scott,

    Thanks. After rebuilding the pininterrupt, it works now.

    In the final code, the edge detect will be alternatively changing. when interrupted with positive edge, negative edge will be set to wait for the next interrupt. when negative edge is detected, positive is set for the next detection.
    There will have two to four I/O to be configured for this pattern.

    To keep using the PIN driver, it needs to config a new setting for edge detect each time when buttonCallbackFxn is called. Is there an API to set the polarity of next edge detection for the particular I/O which detects the edge, instead of using " buttonPinHandle = PIN_open(&buttonPinState, buttonPinTable);" ? with four I/O, it needs 16 set of buttonPinTable and it may use unnecessary cpu power to re-configure the unaffected I/O. I try to keep it as low power as possible and the idle mode has to be very low power.

    Regards,
    Thomas
  • Thomas,

    Have you tried using PIN_setConfig()?

    Thanks,
    Scott

  • Thanks Scott, the solutions work well. For alternative edge detect, now I try to use both edges for interrupt, seems no issues so far.