• State Resolved
  • Locked Locked
  • Replies 45 replies
  • Subscribers 32 subscribers
  • Views 14411 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.

CCS/DK-TM4C129X: Gnu TM4C129X NDK client example link errors

Leo Bredehoft58
Expert 1260 points
Part Number: DK-TM4C129X
Other Parts Discussed in Thread: SYSBIOS, TM4C129XNCZAD

Tool/software: Code Composer Studio

I was unable to find a TM4C129X version of the NDK client, which has an HTTP server I am interested in, so I am porting the client in nsp_1_10_03_15/packages/ti/ndk/examples/ndk_evm6748_elf_examples.zip to the DK-TM4C129X.  After merging and some corrections, I still have three linker errors:

**** Build of configuration Debug__GNU for project ndk_client ****

 

"C:\\ti\\ccsv6\\utils\\bin\\gmake" -k -j 8 all

making ../src/sysbios/sysbios.am4fg ...

gmake[1]: Entering directory `C:/Users/bredel1/Desktop/blueFire/Instrument/Networked/firmware/ndk_client/src/sysbios'

gmake[1]: Nothing to be done for `all'.

gmake[1]: Leaving directory `C:/Users/bredel1/Desktop/blueFire/Instrument/Networked/firmware/ndk_client/src/sysbios'

'Building target: ndk_client.out'

'Invoking: GNU Linker'

"C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc.exe" -march=armv7e-m -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-exceptions -DPART_TM4C129XNCZAD -ffunction-sections -fdata-sections -g -gdwarf-3 -gstrict-dwarf -Wall -Wl,-Map,"ndk_client.map" -L"C:/ti/tirtos_tivac_2_16_01_14/products/TivaWare_C_Series-2.1.1.71b/driverlib/gcc" -L"C:/ti/tirtos_tivac_2_16_01_14/products/TivaWare_C_Series-2.1.1.71b/grlib/gcc" -L"C:/ti/tirtos_tivac_2_16_01_14/products/TivaWare_C_Series-2.1.1.71b/usblib/gcc" -o"ndk_client.out" "./DK_TM4C129X.o" "./client.o" "./emacHooks.o" "./netHooks.o" "./webpage.o" "../src/sysbios/_BIOS.o" "../src/sysbios/gates_GateHwi.o" "../src/sysbios/gates_GateMutex.o" "../src/sysbios/gnu_ReentSupport.o" "../src/sysbios/gnu_SemiHostSupport.o" "../src/sysbios/hal_Cache.o" "../src/sysbios/hal_CacheNull.o" "../src/sysbios/hal_Hwi.o" "../src/sysbios/hal_Hwi_stack.o" "../src/sysbios/hal_Hwi_startup.o" "../src/sysbios/heaps_HeapMem.o" "../src/sysbios/knl_Clock.o" "../src/sysbios/knl_Event.o" "../src/sysbios/knl_Idle.o" "../src/sysbios/knl_Intrinsics.o" "../src/sysbios/knl_Queue.o" "../src/sysbios/knl_Semaphore.o" "../src/sysbios/knl_Swi.o" "../src/sysbios/knl_Swi_andn.o" "../src/sysbios/knl_Task.o" "../src/sysbios/lm4_Timer.o" "../src/sysbios/m3_Hwi.o" "../src/sysbios/m3_Hwi_asm_gnu.o" "../src/sysbios/m3_Hwi_asm_switch_gnu.o" "../src/sysbios/m3_IntrinsicsSupport_asm_gnu.o" "../src/sysbios/m3_TaskSupport.o" "../src/sysbios/m3_TaskSupport_asm_gnu.o" -Wl,-T"../tm4c129xnczad.lds" -Wl,-T"configPkg/linker.cmd" -Wl,--start-group -l"usb" -l"driver" -l"gcc" -l"m" -l"rdimon" -l"c" -Wl,--end-group

 

C:\ti\tirtos_tivac_2_16_01_14\products\bios_6_45_02_31\packages\gnu\targets\arm\rtsv7M\lib\boot.am4fg(startup.om4fg): In function `_fini':

/db/vtree/library/trees/zumaprod/zumaprod-j14/exports/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages/gnu/targets/arm/rtsv7M/startup.c:91: multiple definition of `_fini'

c:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu/crti.o:(.fini+0x0): first defined here

C:\ti\tirtos_tivac_2_16_01_14\products\bios_6_45_02_31\packages\gnu\targets\arm\rtsv7M\lib\boot.am4fg(startup.om4fg):(.data.__dso_handle+0x0): multiple definition of `__dso_handle'

c:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu/crtbegin.o:(.data+0x0): first defined here

 

C:\Users\bredel1\Desktop\blueFire\Instrument\Networked\firmware\ndk_client\Debug__GNU\configPkg\package\cfg\client_pm4fg.om4fg: In function `ti_sysbios_hal_Hwi_HwiProxy_getCoreStackInfo__E':

C:\Users\bredel1\Desktop\blueFire\Instrument\Networked\firmware\ndk_client\Debug__GNU\configPkg/package/cfg/client_pm4fg.c:15447: undefined reference to `ti_sysbios_family_arm_m3_Hwi_getCoreStackInfo__E'

 

collect2.exe: error: ld returned 1 exit status

gmake: *** [ndk_client.out] Error 1

gmake: Target `all' not remade because of errors.

 

**** Build Finished ****

To deal with the duplicate definitions, I have tried removing individual libraries from the project properties linker list, but the errors persist.  I don't know of any way to remove crti.o, crtbegin.o or boot.am4fg from the link, so I am stuck on this problem.

It appears that file Hwi_asm_switch_gun.sv7m should supply ti_sysbios_family_arm_m3_Hwi_getCoreStackInfo__E, but it doesn't.  As a temporary workaround, I can make the error go away by supplying an empty function with that name, but that isn't a solution.

 

Does anyone have ideas on how to fix these problems?

 

Thanks,

Leo Bredehoft

  • 0
    TI__Guru* 96960 points
    The EMAC driver for TM4C129 devices is in TI-RTOS for TivaC. You can get it from here: software-dl.ti.com/.../index.html

    There are simple networking examples (e.g. TCP Echo) that you can use to make sure everything is working okay. Here's an example of how to use the HTTP server on the TM4C129 LP also: processors.wiki.ti.com/.../TI-RTOS_HTTP_Example

    Todd
  • 0 in reply to ToddMullanix
    Expert 1260 points
    This is good information!

    As a part of this effort, I'm attempting to see whether NDK is so memory-hungry that it will crowd out my application. I know that LWIP is conservative, so that is an alternative I'm considering too.

    When I'm done, the project should incorporate
    1) An HTTP server to
    a) serve up microSD FAT files,
    b) serve a chunked binary stream to GET requests.
    2) A hardware-based IEEE 1588 ptpd.
    3) A bidirectional socket serving a proprietary protocol.
    4) ICMP responses to ping.
    5) A DHCP client.
    6) Proprietary hardware stuff.
    7) FatFs with short filenames (A problem with SD card access?).

    This should all run under TI-RTOS to permit spartan use of the processor. I have implemented this kind of system already with SafeRTOS, NicheStack and HCC Embedded FAT FS on an LM3S9B96, so I know this sort of thing can be made to fit, but no memory waste is permitted. If you have more comments, they are welcome.
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points
    The NDK should be able to handle all that. The wiki write-up I gave you includes a section on getting files from FatFS on an SD card. There is support for long filenames also, but if you need it.
  • 0
    TI__Guru**** 191906 points
    On top of the links referenced by Todd, here is another one that maybe useful. processors.wiki.ti.com/.../TI-RTOS_Examples_SemiHosting
  • 0 in reply to Charles Tsai
    Expert 1260 points
    Thanks for the information. I have the code you suggested running on the DK-4C129X, under the TI tools. After some adjustment, I think it is almost linking under GCC, which is a requirement for this project. I see the following errors:

    /db/vtree/library/trees/zumaprod/zumaprod-j14/exports/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages/gnu/targets/arm/rtsv7M/startup.c:91: multiple definition of `_fini'
    c:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu/crti.o:(.fini+0x0): first defined here

    C:\ti\tirtos_tivac_2_16_01_14\products\bios_6_45_02_31\packages\gnu\targets\arm\rtsv7M\lib\boot.am4fg(startup.om4fg):(.data.__dso_handle+0x0): multiple definition of `__dso_handle'
    c:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu/crtbegin.o:(.data+0x0): first defined here

    C:\Users\bredel1\Desktop\blueFire\Instrument\Networked\firmware\httpServer_withSD\Debug__GNU\configPkg\package\cfg\empty_pm4fg.om4fg: In function `ti_sysbios_hal_Hwi_HwiProxy_getCoreStackInfo__E':
    C:\Users\bredel1\Desktop\blueFire\Instrument\Networked\firmware\httpServer_withSD\Debug__GNU\configPkg/package/cfg/empty_pm4fg.c:15827: undefined reference to `ti_sysbios_family_arm_m3_Hwi_getCoreStackInfo__E'

    C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/lib/drivers_wifi_tivaware.am4fg(osi_tirtos.om4fg): In function `vSimpleLinkSpawnTask':
    /db/vtree/library/trees/zumaprod/zumaprod-j14/exports/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/wifi/osi_tirtos.c:475: undefined reference to `ti_sysbios_knl_Mailbox_pend__E'

    Similar mailbox errors have been deleted.

    My questions are:

    1) What and where are the libraries/source files/object files containing TI-RTOS mailbox functionality and getCoreStackInfo() for GCC?
    2) How do I best eliminate the duplicate symbols?
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I'm currently running a clean and build of the libraries from a cmd window:

    c:
    cd \ti\tirtos_tivac_2_16_01_14
    c:\ti\xdctools_3_32_00_06_core\gmake -f tirtos.mak GCC_BUILD=true clean
    c:\ti\xdctools_3_32_00_06_core\gmake -f tirtos.mak GCC_BUILD=true drivers bios ndk uia

    This will hopefully make the missing mailbox stuff reappear. From the contents of tirtos.mak, I expect this to rebuild libraries for the both the TI and Gnu toolsets.

    The "clean" step completed, but the build step gets this:

    C:\ti\tirtos_tivac_2_16_01_14>\ti\xdctools_3_32_00_06_core\gmake -f tirtos.mak C
    CS_BUILD=false GCC_BUILD=true drivers bios ndk uia
    building tirtos drivers...
    gmake[1]: Entering directory `c:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_t
    ivac_2_16_01_13'
    building drivers packages ...making all: Thu Apr 6 09:32:21 MDT 2017 ...
    ======== .interfaces [./packages/ti/boards] ========
    ======== .interfaces [./packages/ti/drivers] ========
    ======== .interfaces [./packages/ti/drivers/ports] ========
    ======== .interfaces [./packages/ti/mw] ========
    ======== .interfaces [./packages/ti/mw/fatfs] ========
    ======== .interfaces [./packages/ti/mw/wifi/cc3x00] ========
    making package.mak (because of package.bld) ...
    making package.mak (because of package.bld) ...
    making package.mak (because of package.bld) ...
    making package.mak (because of package.bld) ...
    making package.mak (because of package.bld) ...
    making package.mak (because of package.bld) ...
    js: "C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/drivers.b
    ld", line 126: xdc.services.global.XDCException: xdc.PACKAGE_NOT_FOUND: C:\ti\ti
    rtos_tivac_2_16_01_14\products\bios_6_45_02_31\packages\gnu\targets\arm\package.
    xdc found along the package path, but no schema file was found. Ensure that the
    package 'gnu.targets.arm' is completely built.
    gmake[1]: *** No rule to make target `package.mak', needed by `.interfaces'. St
    op.
    xdctools_3_32_00_06_core\gmake.exe: *** [packages/ti/drivers/ports,.interfaces]
    Error 2

    How do I build gnu.targets.arm?
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    Gnu.targets.arm.M4F seems to be the directory c:\ti\ccsv6\tools\compiler\gcc-arm-nonw-eabi-4_8-2014q3. There are files named "Makefile" under this path, but none look like a master makefile. I tried

    c:\ti\xdctools_3_32_00_06_core\gmake -f tirtos.mak drivers bios ndk uia

    to build only the TI toolset versions of the libraries, and the make complains that ti.targets.arm.elf is not built. Where is the build script/makefile that builds these targets?
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I wonder if the "clean" step wiped out files which can only be built by TI. Where should I go from here? CCS reinstall? I only got my current install to work by some manual effort, because the CCS App Center couldn't connect to the TI server. My manual efforts may have led to the original inability to build which started this thread. Do you expect the Gnu toolset to be able to compile to this target with this application code, or are there issues with Gnu under CCS?
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points
    Why are you rebuilding all the TI-RTOS product? Can you re-install TI-RTOS and then import the TCP Echo example via Resource Explorer (details are in the Getting Start Guide). Does it build properly?
  • 0 in reply to ToddMullanix
    Expert 1260 points
    I was able to build the HTTP server code you provided to me using the PowerPoint instructions just fine for my DK-TM4C129X. The httpServer_withSD responded to Internet Explorer, and I was able to call up .jpg images, see index.htm, and the CGI time function worked just fine. I started it last night, and it was still working when I got in this morning.

    Now, I'm attempting to get the code to compile under Gnu. There were a few include directory and linker setup issues which I was able to surmount, but I ended up with non linkable code, with the duplicate and missing symbols listed above. My assumption was that the Gnu toolset was perhaps not completely built for TI-RTOS. It seemed that a rebuild might help.

    I'll install TI_RTOS and look at the TCP Echo example, compiled with Gnu. If it works, I imagine I'll still have the link issues with the HTTP server.

    Thanks for your guidance.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points

    I reinstall TI-RTOS.  Using the TI toolset httpServer_withSD works fine under Internet Explorer, once I modify ffconf.h and recompile per the PowerPoint.  TcpEcho_... responds properly to tcpSendReceive.

    Building httpServer_withSD under Gnu using a hacked version of tcpEcho.cfg leaves me with only these errors:

    /db/vtree/library/trees/zumaprod/zumaprod-j14/exports/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages/gnu/targets/arm/rtsv7M/startup.c:91: multiple definition of `_fini'

    c:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu/crti.o:(.fini+0x0): first defined here

    C:\ti\tirtos_tivac_2_16_01_14\products\bios_6_45_02_31\packages\gnu\targets\arm\rtsv7M\lib\boot.am4fg(startup.om4fg):(.data.__dso_handle+0x0): multiple definition of `__dso_handle'

    c:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu/crtbegin.o:(.data+0x0): first defined here

    C:\Users\bredel1\Desktop\blueFire\Instrument\Networked\firmware\httpServer_withSD\Debug__GNU\configPkg\package\cfg\empty_pm4fg.om4fg: In function `ti_sysbios_hal_Hwi_HwiProxy_getCoreStackInfo__E':

    C:\Users\bredel1\Desktop\blueFire\Instrument\Networked\firmware\httpServer_withSD\Debug__GNU\configPkg/package/cfg/empty_pm4fg.c:16008: undefined reference to `ti_sysbios_family_arm_m3_Hwi_getCoreStackInfo__E'

    These errors have always resulted from the Gnu build.  If I can fix them, I can proceed.  How do I fix them?

  • 0 in reply to Leo Bredehoft58
    Expert 1260 points

    According to http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_42_03_35/exports/bios_6_42_03_35/docs/cdoc/ti/sysbios/family/arm/m3/Hwi.html, getCoreStackInfo() is to check for stack overflows on multicore processors.  If I provide a dummy which never returns an indication of overflow, the link error disappears.  I can probably live without stack checking for the time being.  It would be nice to ultimately have a fix, though.

    This leaves only the duplicate labels.  I don't know how to remove the duplicate object files or library from the link, and I don't even know which should be removed.

  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points
    Did you start with a GCC (GNU) version of TCP Echo or attempt to change the TI Compiler example to be GCC? I highly recommend the former. What did you hack in the .cfg?
  • 0 in reply to ToddMullanix
    Expert 1260 points
    I started with the Gnu version of tcpEcho. Here are the differences:

    [bredel1@BREDEL1-L2 httpServer_withSD]# diff ../tcpEcho_DK_TM4C129X_GNU_TivaTM4C129XNCZAD/tcpEcho.cfg empty.cfg
    545a546,548
    > var FatFS = xdc.useModule('ti.mw.fatfs.FatFS');
    > var Timestamp = xdc.useModule('xdc.runtime.Timestamp');
    > var Mailbox = xdc.useModule('ti.sysbios.knl.Mailbox');
    549c552
    < Global.networkOpenHook = "&netOpenHook";
    ---
    > //Global.networkOpenHook = "&netOpenHook";
    561c564
    < Tcp.receiveBufSize = 1024;
    \ No newline at end of file
    ---
    > Tcp.receiveBufSize = 1024;
    [bredel1@BREDEL1-L2 httpServer_withSD]#
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    If you can indicate which duplicate should be removed, I'll be happy to do temporary surgery on the .o sources, or the library, pending attention from your developers.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I think that TI would probably prefer to retain its own code, rather than the code provided with Gnu, so I assume that the Gnu symbols should be excluded. The following produces an image which works from Internet Explorer:

    cd /cygdrive/c/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu
    cp crtbegin.o crtbegin.o.original
    cp crti.o crti.o.original
    /cygdrive/c/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-objcopy crti.o --redefine-sym _fini=_fini_renamed
    /cygdrive/c/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-objcopy crtbegin.o --redefine-sym __dso_handle=__dso_handle_renamed

    But the image is 236K long. More work is required yet.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    Oops. It doesn't work with IE, but it does get a DHCP address.
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points

    I went through the steps in the PPT but started with the GNU empty project. I did hit a symbols problem. There were several unresolved efs_* functions. The work-around for this is to

    1. add :os.am4fg in the libraries

    2. add C:\ti\tirtos_tivac_2_16_01_14\products\ndk_2_25_00_09\packages\ti\ndk\os\lib\ into the library path.

    The problem is an ordering of libraries in the generated linker.cmd file.

    I'm not sure what road you took to get the __dso_handle issue. Can you try following the PPT exactly except use the GNU Empty instead of the TI Compiler Empty project. Then before slide 21, add the above work-around.

    Todd

  • 0 in reply to ToddMullanix
    Expert 1260 points
    The build is linking and running on IE, but it refuses to link in efs_stdio.c, so all file accesses fail, trying to go through SemiHosting:

    CORTEX_M4_0: GEL Output:
    Memory Map Initialization Complete
    CORTEX_M4_0: SemiHosting : File IO Error : fopen() : 0:index.html : No such file or directory

    How do I force the linker to include efs_stdio.c and ignore the EFS library code? I took out the above linker changes, but that doesn't help. I don't have a problem with getting the EFS library code. I want to keep from doing so.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I did go through the steps in the PPT, as you requested, to get where I am now.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    Efs_createfile() in efs_stdio.c is being called properly from AddWebFiles(). Efs_stdio.c is visible in the .map file. No code is being generated for any other function in efs_stdio.c. This seems to make all of the FatFS routines in ti.mw.fatfs.am4fg inaccessible. In the .map file, the FatFS routines and efs_stdio.c FatFS interface routines are listed under "Discarded input sections". What is it that makes SemiHosting take precedence over FatFS? If this issue is addressed, it may be possible to link and run.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I would like to be able to run a Gnu image from the debugger or standalone, probably using the UART, like with the TI tools. Can I purge SemiHosting from my build and get that behavior?
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    After experimenting with shutting off SemiHostSupport in empty.cfg and replacing rdimon with nosys, then putting both items back like they were, efs_fopen() now calls into the linaro fopen(), which fails and results in a 404 in IE. I would expect the call to call into FatFS, which it doesn't. The .map shows fatfs among the discarded input sections. Why?
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I have done a "clean" in between builds, just in case.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    It appears that CCS provides a file I/O abstraction library, described in c:\ti\ccsv6\tools\compiler\ti-cgt-arm-*.*.*/lib/src/file.h. FatFS inclusion is enabled in the autogenerated Debug/configPkg/package/cfg/*_pm4fg.c with the #define __ti__, which is presumably a TI tools indicator. This keeps GCC from registering the FatFS access routines with the abstraction layer, excluding them from the linker map. Under the reasonable presumption that the #ifdef indicates that there is no abstraction support in the library for GCC, any access to FatFS by GCC code must be direct, without the abstraction layer. This explains why microSD files are not visible from GCC code attempting to use the abstraction layer.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    Is this true? If so, can I expect to see other TI-RTOS functions not supported under GCC?
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    Is TI-RTOS supported under GCC?
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I found the answer to this here: e2e.ti.com/.../427531. We can close the issue.
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points
    That's an old thread. We support GCC on TM4C.
  • 0 in reply to ToddMullanix
    Expert 1260 points

    That's great to hear, but I still have the problem that an #ifdef __ti__ in build-generated Debug/configPkg/package/cfg/*_pm4fg.c silently disables calls to to FatFS when building with GCC.  How do I fix this?  This problem is explained farther up in the thread.  Thanks.

  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I just realized that this thread was marked "answered," so I just rejected the answer so it could be seen by the right people.
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points
    Something is fishy here. Can you attach your built project?
  • 0 in reply to ToddMullanix
    Expert 1260 points

    I was unable to get the build to happen because when the target is changed back to Gnu, the Properties->General->RTSC Target and/or Platform are still for the TI tools.  I knew how to fix this when I was doing Gnu builds, but I don't remember the proper target right now.  We'll have to either wait until I can find that out, or perhaps you know it already.  I'm currently attempting to find out how to attach a file in e2e.  I don't see any "upload" button or anything like that.  I'll send it as soon as I find out how.

  • 0 in reply to Leo Bredehoft58
    Expert 1260 points

    httpServer_withSD.zipThe unbuilt project is attached.

  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I just tried to make a fresh Gnu project, and it doesn't even have an RTSC page, so there's no hint as to the right target name there.
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    In attempting to recreate the original "missing FatFS under Gnu" problem, I am getting all kinds of undefined and duplicate references. I can't afford to take the time to guess my way into becoming an expert at the internals of CCS. The only workable solution for me is to have TI provide a worked example of an HTTP server with microSD FatFS and TI-RTOS, built with GCC, which runs on the TM4C129X. If this can't be made to happen, that's okay, and I will live with the TI tools, since at least I can build a working image with them. You're welcome to use the source I sent you to do this, but, I simply can't be doing this myself. Thanks.
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points
    Your project is not correct. It appears you did not start with the GCC empty project. There are several items wrong with it. Can you please start with the GCC empty example and proceed with the PPT instructions. The one caveat is that the :os.am4fg library must be manually added (as noted earlier). If you hit a problem, please don't start making changes. Simply post the issue. It's really hard on my end to understand what is happening when you make changes to get it past an issue. You could be simply masking a problem that pops up latter.

    I have the example built with GCC but need to find an SD boosterpack to test it first.

    Todd
  • 0 in reply to ToddMullanix
    Expert 1260 points
    Sorry for causing you the trouble, but today I did attempt to switch my working TI tools build back to GCC to produce a failing build for you. Earlier, I got to the FatFS issue using the PPT approach just as you recommended and decided on my own that the only supported option for TI-RTOS (FatFS) was under the TI tools, proceeding on that path.

    I'm very motivated to use the Gnu tools, for various reasons. As an example, I have a performance-critical 60M bit/second inner-loop bit packing task which I coded using G++ with its very-capable asm() facility to get something which is quite close to hand-coded assembly, without the effort. My current plan is to take the generated assembly and actually edit/reassemble it to work under the TI toolset. Simply using GCC directly is, of course, far preferable. I anticipate similar situations to arise later as well.

    The TM4C129X Development Board I have has a microSD socket on it, so I'm not sure why a booster pack is needed. Are we talking about the same board? Does the built example actually link in f_open(), f_read(), etc. from FatFS? I'm pretty sure that that is what kept my build from accessing the microSD.

    Thanks very much for your help.

    Best regards,
    Leo
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points

    I have the LaunchPad. I found a SD boosterpack. You'll need to use the raw FatFS APIs (e.g. f_open instead of fopen). With the TI Compiler we can stick the necessary functions under the RTS calls (e.g. fopen eventually calls f_open). The GCC RTS is different. You have to supply an alternative implement for fopen (80% sure about that...) and we have not done that. It's on the list, but no timeframe. The work-around for this is to use raw FatFS APIs.

    I can tweak the efs_stdio.c file in the example if you want but the earliest I can get to it is next week.

  • 0 in reply to ToddMullanix
    Expert 1260 points
    Excellent! Confirmation of nonimplemented FatFS is enough I think for me to proceed. My greater concern was that there was more which wasn't working under GCC, which I'm going to assume is not the case. You don't need to do anything with efs_stdio.c. I will start working on reproduction of the build using the PPT instructions, with the efs_stdio.c changes. But, if you have the time, could you please zip together the compiling project after a build "clean," to make it small, then attach it to this thread? That would speed things up on my end. If there is anything else known not to work yet under GCC, please let me know. Many thanks.
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points

    Here is the project. The efs_stdio.h needs to be modified to use the raw FatFS APIs. It also does not have any long filename changes (as outlined in the PPT). I used CCS 7.1.

    HttpGNU.zip

  • 0 in reply to ToddMullanix
    Expert 1260 points
    I installed CCS 7.1, imported the project to a DK_TM4C129X Gnu project, modified efs_stdio.c to make use of FatFS and modified to use long filenames, as outlined in the PPT. The application responds to IE, but f_open() returns FR_INVALID_NAME, from follow_path(). I'm starting to debug the f_open() rejection of the filename "0:index.html". Any suggestions would be appreciated.
  • 0 in reply to Leo Bredehoft58
    TI__Guru* 96960 points
    Have you tried the FatSD Raw example to verify the SD card, etc. is working properly?
  • 0 in reply to ToddMullanix
    Expert 1260 points
    I have switched over to the TI tool set, since performance with it is better anyway.