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.

  • TI Thinks Resolved

Compiler/TIDM-TM4C129XNFC: TI-RTOS 2.16 Project Upgrade Procedure

Part Number: TIDM-TM4C129XNFC

Tool/software: TI C/C++ Compiler

Hi,

I'm trying to get the http://www.ti.com/tool/TIDM-TM4C129XNFC 

Once I switch from TI-RTOS 2.14 to 2.16, I get the following errors. I guessed some functionality has moved into the framework, so I tried removing the CC3100 board code (however this didn't help). 

Any ideas on a way forward?

Thanks in advance,

Tim

Errors were: 

error #10056: symbol "registerInterruptHandler" redefined: first defined in "./CC3100_board.obj"; redefined in "C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/lib/drivers_wifi_tivaware.aem4f<WiFiCC3100.oem4f>"

error #10056: symbol "spi_Read" redefined: first defined in "./CC3100_spi.obj"; redefined in "C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/lib/drivers_wifi_tivaware.aem4f<WiFiCC3100.oem4f>"

error #10056: symbol "spi_Close" redefined: first defined in "./CC3100_spi.obj"; redefined in "C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/lib/drivers_wifi_tivaware.aem4f<WiFiCC3100.oem4f>"

error #10056: symbol "spi_Write" redefined: first defined in "./CC3100_spi.obj"; redefined in "C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/lib/drivers_wifi_tivaware.aem4f<WiFiCC3100.oem4f>"

error #10056: symbol "spi_Open" redefined: first defined in "./CC3100_spi.obj"; redefined in "C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/lib/drivers_wifi_tivaware.aem4f<WiFiCC3100.oem4f>"

error #10010: errors encountered during linking; 

>> Compilation failure

**** Build Finished ****

  • Hello Tim,

    Just looking at the errors, it seems there are now a few functions which are declared in two separate locations. I would suggest viewing each declaration and then understanding which one you need. For the one you don't typically you would want to comment it out, but as one declaration lays in the RTOS folder, you need to be careful because modifying any of those files will affect all other RTOS projects you have. If you do need to modify those files, you may want to make a separate RTOS install folder just for this project so can modify the files without future repercussions .

    The RTOS team might be able to offer further feedback, but hopefully this will help you get going.

    Best Regards,

    Ralph Jacobi

  • In reply to Ralph Jacobi:

    Tim,

    Can put the full build output into a file and attach that file?

    Todd
  • In reply to ToddMullanix:

    Hi Ralph & Todd,

    On further investigation, I can build successfully by adding the following to the bottom of app.cfg:

    var mwConfig = xdc.useModule('ti.mw.Config');

    mwConfig.provideWiFiCC3X00Lib = false; 

    Unfortunately, when I launch the app it complains about interrupt 88:


    There are also some middleware warnings:

    I would really like to set mwConfig.provideWiFiCC3X00Lib = true; so the middleware can handle the CC3100 and the interrupt 88 issue is resolved. How should I approach this? I'm not really clear on how to go about this.

    To assist, I've attached the output for each scenario (when mwConfig.provideWiFiCC3X00Lib is set to either true or false.).

    I have also attached the project, which can be re-created easily by downloading the TI-RTOS 2.14 WIFI+NFC project and updating it to TI-RTOS 2.16.

    Thank you so much for your help, I've been pulling my hair out on this problem for weeks now!

    Cheers,

    Tim

    Build with mwConfig.provideWiFiCC3X00Lib_false.txt

    Build with mwConfig.provideWiFiCC3X00Lib_true.txt

    tiva_wifi_nfc_ap.zip

  • In reply to Ralph Jacobi:

    Ralph Jacobi
    I would suggest viewing each declaration and then understanding which one you need.    For the one you don't typically (need) you would want to comment it out, but as one declaration lays in the RTOS folder, you need to be careful because modifying any of those files will affect all other RTOS projects

    Three "LIKEs" from our crack (working Saturday) crüe, Ralph!

    Note that the "highlight" ended in "you have."     (deleted as such "modification" it will impact,  "ALL FUTURE Projects" - as well ... thus great the POWER of your well chosen advice!

  • In reply to cb1_mobile:

    I will not change anything in the RTOS folder, since that's asking for trouble!

    I'm looking for guidance on how to get the Host Driver Implementation out of user.h and handled by the middleware (mwConfig.provideWiFiCC3X00Lib = true;)

    Cheers,

    Tim

  • In reply to Tim Roadley:

    Update:

    If I try to comment out the conflicting functions in CC3100_board.c and CC3100_spi.c then the program runs however crashes straight away. I sort of expected this since it doesn't feel like I've properly moved to the middleware driver. I'm missing something...

  • In reply to Tim Roadley:

    Tim,

    Have you looked at the TCP Echo WiFi example in the TI-RTOS 2.16 product? Can you get that to build and run? Did you have your application working with TI-RTOS 2.14?

    Todd
  • In reply to ToddMullanix:

    Hi Todd,

    I have the following findings:

    - I can run the other wifi examples without a problem, so long as the CC3100 is in slot 1 on the TM4C.

    - All of my issues stem from me needing to run the CC3100 in slot 2 on the TM4C.

    - When I use the middleware to handle the CC3100, I get the HWI already defined errors. (E_alreadyDefined: Hwi already defined: intr# 88)

    - I can prevent the HWI already defined errors by commenting out  the following in EK_TM4C1294XL.c:

    /* CC3100 IRQ (Raising Edge) */

    // GPIOTiva_PM_7 | GPIO_CFG_INPUT | GPIO_CFG_IN_INT_RISING, // CAUSES ti.sysbios.family.arm.m3.Hwi: line 143: E_alreadyDefined: Hwi already defined: intr# 88

    This of course means that the middleware is now totally handling the CC3100, however I've no idea how to tell the middleware that the CC3100 is in slot 2.

    - If I disable the middleware from managing the CC3100 I get the following errors, which I'm not sure how to solve:

    Thanks for your help so far!

    Cheers,

    Tim

  • In reply to Tim Roadley:

    Tim,

    I'm doing a little clean-up. I'm assuming that this can be closed because the issue was handled in the other thread...correct?

    Todd

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.