• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Subscribers 31 subscribers
  • Views 6692 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/EK-TM4C1294XL: Hwi already defined, Invalid EPSR and instruction combination

Tim Roadley
Intellectual 730 points
Part Number: EK-TM4C1294XL
Other Parts Discussed in Thread: CC3100, SYSBIOS, , TRF7970A

Tool/software: TI-RTOS

Hi,

Having finally got through the issues mentioned in this article, I've hit another issue I'm not sure how to troubleshoot.

I'm running the CC3100 http client demo, integrated into my own application.

When the application launches, I get a warning "ti.sysbios.family.arm.m3.Hwi: line 143: E_alreadyDefined: Hwi already defined: intr# 88".

Later, when the http client attempts to POST to a HTTP server, the application crashes with the following error:

Do you have any tips for getting to the bottom of this issue? I suspect the redefinition of hwi might have something to do with this, however I'm not exactly sure how to fix this!

Thanks in advance for your help!

Cheers,

Tim

  • 0
    Intellectual 730 points

    Silly question, I'm using an EK-TM4C1294XL, which I believe has a CORTEX M4. Does this mean ti.sysbios.familty.arm.m3 is wrong and ti.sysbios.familty.arm.m4 should be used instead?

    In case it helps, here are a bunch more screenshots from the crash :

  • 0 in reply to Tim Roadley
    TI__Guru* 96960 points
    Hi Tim,

    Let's get the duplicate Hwi resolved first. The m3 is the correct name. We started with the Stellaris LM3 devices and used the "m3" name and then we were kinda of stuck with it...hindsight is 20/20:(

    Thanks for posting the ROV snapshots. Who is plugging in GPIOM_intHandler as the Hwi function? If it is you, are you trying to do it twice? Can you confirm you using the Hwi module to plug the interrupts and not the driverlib interrupt module. They don't play nice with each other.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 730 points

    Hi Todd,

    Thanks for your reply.

    I'm using sample code combined from the CC3100 http client and TRF7970A Wifi NFC examples.

    If I search for GPIOM_intHandler, I find it in CC3100_board.h and Debug/configPkgcfg/app_pem4f.c


     

    I suspect that perhaps I have selected the incorrect hardware in the project properties, or I have some fundamental configuration issue.

    With this in mind, my exact hardware is an EK-TM4C1294XL board with a wifi booster pack (CC3100) and NFC booster pack (TRF7970).

    In the project properties, the closest thing in the project config to a EK-TM4C1294XL is as follows. No matter which one of the three close matches I choose, the 'duplicate twi' and crash still occurs.

    Other stuff that might matter is the following, can you confirm that looks ok?

    Thanks for your assistance so far, I'll continue to troubleshoot and post an update if I make any progress.

    Cheers,

    Tim

  • 0 in reply to Tim Roadley
    Guru 55973 points
    Hi Tim,

    Did you get it to work yet?
  • 0 in reply to Genatco
    Intellectual 730 points
    Unfortunately not yet, I’ve still got the crash issue.. I suspect the issue might be due to the hardware variant I’ve selected, can you confirm in my last post that I’m using the corrrect one?
  • 0 in reply to Tim Roadley
    Guru 55973 points

    Tim Roadley said:
    Unfortunately not yet, I’ve still got the crash issue.. I suspect the issue might be due to the hardware variant I’ve selected, can you confirm in my last post that I’m using the corrrect one?

    The variant is more relative to flash memory size of MCU. Todd mentions M3 module HWI instance handlers playing badly with Tivaware. You may need to deprecate (startup_ccs.c) interrupts into M3 HWI module, remove from project build.  

  • 0 in reply to Tim Roadley
    Guru 55973 points

    We disable this code being no WiFi module is attached on booster headers, compiler was barking warnings etc... 

  • 0 in reply to Genatco
    Intellectual 730 points

    I'd be surprised if provideWiFiCC3X00Lib were set to false. My hardware is this and the project I'm running is this, which all works (wifi included).

    The issues started once I tried to enhance this project with the http client code from the SDK. I'm now getting a 'duplicate hwi' error as described in the trail above and the application now crashes when I try to post anything, which is also described above.

    Where can I find the mwConfig you've shown in the screenshot above? I could not find any reference to provideWiFiCC3X00Lib in my project.

    Thanks in advance for your help!

    Cheers,

    Tim

  • 0 in reply to Genatco
    Intellectual 730 points
    How would I go about deprecating the startup_ccs.c interrupts into the M3 HWI module? I can't find this file in my project (which as I mentioned is based on tiva_wifi_nfc_ap example code project from here: www.ti.com/.../tidcav8

    Would this be done in EK_TM4C1294XL.h, EK_TM4C1294XL.c or somewhere else?
  • 0 in reply to Tim Roadley
    Guru 55973 points

    Not getting emails for this thread~

    Had figured it was a Tivaware WiFi example you tired to migrate into RTOS. If it was RTOS to begin with it would not have startup interrupt vectors. In that case all your HW interrupts might be registered in HWI module.

    That RTOS WiFi module was posting several compiler warnings so I set it to false so it would stop loading module headers. Not sure it your WiFi code used the same library but worth looking into.

  • 0 in reply to Genatco
    Intellectual 730 points

    Ah ok, honestly I'm (quite) a bit out of my depth with this stuff!

    Exactly where would I go to stop the RTOS WiFi module from loading module headers?

    Thanks for your patience!

    Cheers

  • 0
    Intellectual 730 points
    I needed to comment out the following in EK_TM4C1294XL.c, since the CC3100 is now handled be the middleware.

    GPIO_PinConfig gpioPinConfigs[] = {
    /* Input pins */
    /* EK_TM4C1294XL_USR_SW1 */
    GPIOTiva_PJ_0 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_NONE,
    /* EK_TM4C1294XL_USR_SW2 */
    GPIOTiva_PJ_1 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_NONE,
    /* TRF7970A IRQ (Raising Edge) */
    GPIOTiva_PC_7 | GPIO_CFG_INPUT | GPIO_CFG_IN_INT_RISING,
    /* CC3100 IRQ (Raising Edge) */
    //GPIOTiva_PM_7 | GPIO_CFG_INPUT | GPIO_CFG_IN_INT_RISING, // THIS CAUSES ti.sysbios.family.arm.m3.Hwi: line 143: E_alreadyDefined: Hwi already defined: intr# 88

    /* Output pins */
    /* EK_TM4C1294XL_USR_D1 */
    GPIOTiva_PN_1 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* EK_TM4C1294XL_USR_D2 */
    GPIOTiva_PN_0 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* EK_TM4C1294XL_USR_D3 */
    GPIOTiva_PF_4 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* EK_TM4C1294XL_USR_D4 */
    GPIOTiva_PF_0 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* TRF7970A EN (Active High) */
    GPIOTiva_PB_3 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_HIGH,
    /* TRF7970A CS (Active Low) */
    GPIOTiva_PB_2 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_HIGH,
    /* CC3100 EN (Active High)*/
    //GPIOTiva_PD_4 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* CC3100 CS (Active Low)*/
    //GPIOTiva_PP_5 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_HIGH,
    };


    In addition, the EK_TM4C1294XL.h needed to be updated too:

    typedef enum EK_TM4C1294XL_GPIOName {
    EK_TM4C1294XL_USR_SW1 = 0,
    EK_TM4C1294XL_USR_SW2,
    EK_TM4C1294XL_TRF7970A_IRQ,
    //EK_TM4C1294XL_CC3100_IRQ,
    EK_TM4C1294XL_D1,
    EK_TM4C1294XL_D2,
    EK_TM4C1294XL_D3,
    EK_TM4C1294XL_D4,
    EK_TM4C1294XL_TRF7970A_EN,
    EK_TM4C1294XL_TRF7970A_CS,
    //EK_TM4C1294XL_CC3100_EN,
    //EK_TM4C1294XL_CC3100_CS,

    EK_TM4C1294XL_GPIOCOUNT
    } EK_TM4C1294XL_GPIOName;
  • 0 in reply to Tim Roadley
    Guru 55973 points

    So TI-RTOS was loading 3100 WiFi middleware on top of your WiFi example configuration as suspected back a few posts.

    Good to see you got it working from your hard investigative work in that endeavor.

  • 0 in reply to Genatco
    Guru 55973 points
    ti_mw_Config.provideWiFiCC3X00Lib = false;
  • 0 in reply to Genatco
    Guru 55973 points

    Think you may have stumbled into new issue with RTOS (ti_mw_Config.provideWiFiCC3X00Lib = false;). CCS linker still tries to find the Symbols (below) EK_TM4C1294XL.c. Recall compiler may have tried to find several WiFi3100 Symbols with earlier version RTOS 2.16.0.08. RTOS configuration file would past stop Symbol errors but no longer has any control as discovered over the weekend and today.

  • 0 in reply to Genatco
    Intellectual 730 points

    Check out this article, which is where I've fully documented the resolution to this issue:  Note that I've enabled the middleware ti_mw_Config.provideWiFiCC3X00Lib = true;

  • 0 in reply to Tim Roadley
    Intellectual 730 points
    Note: My initWiFi code works, you also need to select the correct SPI in Board.h as discussed in that article above.
  • 0 in reply to Tim Roadley
    Guru 55973 points
    I get that you finally modified GPIO SPI ports in other threads yet when trying to disable WiFi library via RTOS Config(ti.mw) it fails to do so. That ain't good at all. So you actually ended up disabling WiFiCC3100 Example GPIO/SPI configurations, a bit opposite from your earlier attempts.

    BTW: I don't see above post where you modified SPI Data0/1 port for BP2 in EK_TM4c1294XL.c , that could give trouble down the road. Seemingly the WiFiCC3100 module is not getting SPI configuration from the (ti.mw) library.
  • 0 in reply to Genatco
    Intellectual 730 points

    Ah I see,

    Check out the attached files, which hopefully makes it clearer what I did to resolve this issue.

    • Board.h
      • Update Board_WIFI_SPI  to EK_TM4C1294XL_SPI3
    • EM_TM4C1294XL.h
      • Update EK_TM4C1294XL_GPIOName to exclude reference to CC3100
    • EM_TM4C1294XL.c
      • Update wiFiCC3100HWAttrs to Slot 2
      • Update EK_TM4C1294XL_initWiFi to Slot 2
    • app.cfg
      • Update mwConfig.provideWiFiCC3X00Lib = true;

    Can I ask why you would not want the middleware to handle the CC3100?

    Move_CC3100_to_Slot2.zip

  • 0 in reply to Tim Roadley
    Guru 55973 points

    Tim Roadley said:
    Can I ask why you would not want the middleware to handle the CC3100?

    I agree too yet your non RTOS projects WiFi GPIO configuration was conflicting with EK_TM4C1294XL.c HWI. That seemed to be your initial issue being you posted GPIO configurations seemingly not copied from the RTOS platform above. Seem to have missed the earlier need for desire to use of BP2 versus BP1, yet did that actually end up causing the HWI issue?

  • 0 in reply to Genatco
    Guru 55973 points
    Multiple threads for same WiFi issue causing some confusion on my part.