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.

Problems with strchr function locking up

Other Parts Discussed in Thread: OMAPL138

Hello!

I am having problems with the strchr function in the TMS compiler (version 5.0.1).  When I step through my code and get to the strchr call, the emulator locks up.  This is the command:

char *pchartest = strchr("Ee", 13);

Does anyone know why this would just hang?  The emulator executes the line and just locks up.  I was expecting a null pointer.

Thanks,

Tim

  • Did you remember to include string.h?

    When you say that it "hangs/locks up", are you able to halt the processor and examine the PC?

    The function strchr is not very demanding in terms of resources; I can't see why it would cause any particular problem.

  • Hey Archaeologist,

    Yes I have included string.h.  I am able to pause and I get the following disassembly at 0xc20b978c:

    c20b9784: E28FE000 ADD R14, PC, #0x0
    c20b9788: E51FF07C LDR PC, _CPUAbortHandler
    loop0:
    c20b978c: EAFFFFFE B loop0
    C$$EXIT, loader_exit:
    c20b9790: E1A00000 MOV R0, R0
    c20b9794: E12FFF1E BX R14

    If you need more let me know.  It is really strange.  It looks like it is caught in a loop.

    Thanks,

    Tim

  • When execution reaches the label C$$EXIT, the program has terminated, and the debugger should stop execution there.  You should see a breakpoint at this label.  C$$EXIT is used for both normal termination (calling exit or running off the end of main), or abnormal termination (calling abort).  Are you sure the program reached C$$EXIT during execution of strchr, or is strchr long finished?

  • I forgot to mention: C$$EXIT is in an infinite loop, in case there is no debugger attached.  In this case, upon "termination", the program will indefinitely loop on the empty loop containing C$$EXIT.

  • The strchr function gets to this line:

    E6EF1071 UUNPK8TO32    R1, R1, ROR #0

    Then it jumps to this line:

     E59FF018 LDR           PC, 0xFFFF0024

    Then it goes to the abort handler:

    AbortHandler, UndefInstHandler:
    c10892bc: E10F0000 MRS R0, CPSR
    c10892c0: E38000C0 ORR R0, R0, #0xC0
    c10892c4: E121F000 MSR CPSR_c, R0
    c10892c8: E28FE000 ADD R14, PC, #0x0
    c10892cc: E51FF07C LDR PC, _CPUAbortHandler

    Then the CPU Abort Handler:

    CPUAbortHandler:
    c10892f0: E12FFF1E BX R14
    113 __R5 = 0; /* to avoid compiler warning*/

    Then the infinite loop0:

    loop0:
    c10892d0: EAFFFFFE B loop0

    Is this some sort of 32 bit thing?  I am running this on an ARM9.

    Thanks,

    Tim

  • UUNPK8TO32 is a pseudo-op which is actually UXTB.  I'm told (by the assembler) that UXTB is not available on ARM9, so most likely what's happening is you are getting an invalid opcode exception, which is being handled by UndefInstHandler, which would have been installed in the interrupt vector.  Please make sure you are using the appropriate compiler option for ARM9 (-mv5e), and that you're linking against a library which the ARM9 can handle.

  • Here is a summary of the compiler flags:

    -mv5e --code_state=32 --abi=eabi -me -g --include_path="C:/ti/ccsv5/tools/compiler/tms470_5.0.1/include" --include_path="../../../../../../../examples/MityDSPL138/usb_dev_serial" --include_path="../../../../../../../include" --include_path="../../../../../../../include/hw" --include_path="../../../../../../../include/armv5" --include_path="../../../../../../../include/armv5/omapl138" --include_path="../../../../../../../grlib/include" --include_path="../../../../../../../usblib/include" --include_path="../../../../../../../ipclite/include" --include_path="../../../../../../../nandlib/include" --gcc --define=omapl138 --diag_warning=225 --display_error_number

    And here is a summary of the linker flags:

    -mv5e --code_state=32 --abi=eabi -me -g --gcc --define=omapl138 --diag_warning=225 --display_error_number -z -m"usb_dev_serial.map" -i"C:/ti/ccsv5/tools/compiler/tms470_5.0.1/lib" -i"C:/ti/ccsv5/tools/compiler/tms470_5.0.1/include" -i"../../../../../../../binary/armv5/cgt_ccs/omapl138/drivers/Debug" -i"../../../../../../../binary/armv5/cgt_ccs/omapl138/MityDSPL138/platform/Debug" -i"../../../../../../../binary/armv5/cgt_ccs/omapl138/system_config/Debug" -i"../../../../../../../binary/armv5/cgt_ccs/omapl138/ipclib/Debug" -i"../../../../../../../binary/armv5/cgt_ccs/omapl138/usblib/Debug" -i"../../../../../../../binary/armv5/cgt_ccs/utils/Debug" -i"../../../../../../../binary/armv5/cgt_ccs/grlib/Debug" -i"../../../../../../../binary/armv5/cgt_ccs/nandlib/Debug" --reread_libs --warn_sections --rom_model

    How do I know if I am linking against a library that the ARM9 can't handle other than the lib directory mentioned in the above linker flags?  This is the usb_dev_serial example that comes with StarterWare.  I added #include "string.h" at the top and the strchr function in the main at the very top after the variable declarations.

    Thanks,

    Tim

  • Look in the linker map file usb_dev_serial.map to see which standard C library was selected.

    Do you have library selection set to "automatic" ?

  • OK.  It is using this library:

    c10893f8 00000028 rtsv7A8_A_le_eabi.lib : strchr.obj (.text)

    As for the automatic, do you mean the Disable Automatic RTS Selection (I have that unchecked)?

    Thanks,

    Tim

  • That's not a compatible library.  It requires a Cortex (v7) A8 device; you have ARM9e (v5e).

    You should have "Disable Automatic RTS Selection" unchecked; it is rare that anyone would want to change that setting.

    There is a separate setting where you pick the RTS library; that should be set to "automatic"

  • It is on automatic.  I just forced it to rtsv5_A_le_eabi.lib right now and it worked.  I assume that is the correct file?

    Thanks for all your help.

    Tim

  • Given your compiler options, yes, that is a compatible library.

    If automatic library selection picked a Cortex-A8 library for you, and you don't have any Cortex-A8 object files in your project, then that is a bug.  Do you have any object files compiled with different options?  Do you perhaps have some object files left over from a previous build with different options?

  • I don't think I do..  Maybe accidently?  How can I tell if the obj files have different options.

  • You'd need to run "armofd -v" on them and examine the section called "Build Attributes."  This will tell you the architecture used to compile the file.

  • I have 3 obj files.  Here are the Build Attributes contents of each:

    usb_dev_serial.obj:

    Build Attributes in ".ARM.attributes"

    Format Version: 'A'

    <0> Vendor Name: "TI" (Texas Instruments, Inc.)

    Tag_File:
    Attributes:
    Tag_Producer_Name Assembler
    Tag_Producer_VMajor 6 (Producer Major Version + 1)
    Tag_Producer_VMinor 1 (Producer Minor Version + 1)
    Tag_Producer_VPatch 2 (Producer Patch Version + 1)
    Tag_ABI 3 (ARM EABI)
    Tag_ISA 4 (ARM v5TE)
    Tag_Bitfield_layout 2 (Compatible with any Bitfield Layout)
    Tag_FP_interface 1
    Tag_ARM_Mode 1 (# input files built in this mode)
    Tag_DATA_syms_exist 1 (Data mapping symbols are present)

    <1> Vendor Name: "aeabi" (ABI for the ARM Architecture)

    Tag_File:
    Attributes:
    Tag_CPU_arch 4 (ARM v5TE)
    Tag_ARM_ISA_use 1 (Some ARM instructions used)
    Tag_ABI_PCS_wchar_t 2 (Size of wchar_t is 2)
    Tag_ABI_FP_number_model 1 (Only IEEE 754 format FP numbers used)
    Tag_ABI_align_needed 1 (8-byte alignment of 8-byte data required)
    Tag_ABI_align_preserved 1 (All required 8-byte alignments are preserved, except for SP in leaf function)
    Tag_ABI_enum_size 1 (Enum values occupy the smallest container big enough to hold all values)
    Tag_ABI_optimization_goals 5 (Optimized for good debugging, but speed and small size preserved)
    Tag_DIV_use 1 (SDIV and UDIV instructions were not permitted)

    usb_serial_structs.obj:

    Build Attributes in ".ARM.attributes"

    Format Version: 'A'

    <0> Vendor Name: "TI" (Texas Instruments, Inc.)

    Tag_File:
    Attributes:
    Tag_Producer_Name Assembler
    Tag_Producer_VMajor 6 (Producer Major Version + 1)
    Tag_Producer_VMinor 1 (Producer Minor Version + 1)
    Tag_Producer_VPatch 2 (Producer Patch Version + 1)
    Tag_ABI 3 (ARM EABI)
    Tag_ISA 4 (ARM v5TE)
    Tag_Bitfield_layout 2 (Compatible with any Bitfield Layout)
    Tag_FP_interface 1
    Tag_ARM_Mode 1 (# input files built in this mode)
    Tag_DATA_syms_exist 1 (Data mapping symbols are present)

    <1> Vendor Name: "aeabi" (ABI for the ARM Architecture)

    Tag_File:
    Attributes:
    Tag_CPU_arch 4 (ARM v5TE)
    Tag_ABI_PCS_wchar_t 2 (Size of wchar_t is 2)
    Tag_ABI_FP_number_model 1 (Only IEEE 754 format FP numbers used)
    Tag_ABI_align_needed 1 (8-byte alignment of 8-byte data required)
    Tag_ABI_align_preserved 1 (All required 8-byte alignments are preserved, except for SP in leaf function)
    Tag_ABI_enum_size 1 (Enum values occupy the smallest container big enough to hold all values)
    Tag_ABI_optimization_goals 5 (Optimized for good debugging, but speed and small size preserved)
    Tag_DIV_use 1 (SDIV and UDIV instructions were not permitted)

    ustdlib.obj:

    Build Attributes in ".ARM.attributes"

    Format Version: 'A'

    <0> Vendor Name: "TI" (Texas Instruments, Inc.)

    Tag_File:
    Attributes:
    Tag_Producer_Name Assembler
    Tag_Producer_VMajor 6 (Producer Major Version + 1)
    Tag_Producer_VMinor 1 (Producer Minor Version + 1)
    Tag_Producer_VPatch 2 (Producer Patch Version + 1)
    Tag_ABI 3 (ARM EABI)
    Tag_ISA 4 (ARM v5TE)
    Tag_Bitfield_layout 2 (Compatible with any Bitfield Layout)
    Tag_FP_interface 1
    Tag_ARM_Mode 1 (# input files built in this mode)
    Tag_DATA_syms_exist 1 (Data mapping symbols are present)

    <1> Vendor Name: "aeabi" (ABI for the ARM Architecture)

    Tag_File:
    Attributes:
    Tag_CPU_arch 4 (ARM v5TE)
    Tag_ARM_ISA_use 1 (Some ARM instructions used)
    Tag_ABI_PCS_wchar_t 2 (Size of wchar_t is 2)
    Tag_ABI_FP_number_model 1 (Only IEEE 754 format FP numbers used)
    Tag_ABI_align_needed 1 (8-byte alignment of 8-byte data required)
    Tag_ABI_align_preserved 1 (All required 8-byte alignments are preserved, except for SP in leaf function)
    Tag_ABI_optimization_goals 5 (Optimized for good debugging, but speed and small size preserved)
    Tag_DIV_use 1 (SDIV and UDIV instructions were not permitted)

  • Tag_CPU_arch is the important one in this case, and those three files all show "ARM v5TE", which agrees with your command-line options. 

    Do you have any library other than the standard C library in your project?

    Could you generate the linker map file (linker option --map_file) and post it here?