Project

General

Profile

DSP HelloWorld Compile with gcc 4.3.3

Added by Doug Browning almost 6 years ago

I've recently completed the ARM HelloWorld example via the Starter Guide Wiki page and need help with the DSP HelloWorld example. My set up is as follows:
- MityDSPL138 Industrial I/O board w/ Angstrom GNU/Linux 20107-test-20110516 (foo) installed on MityDSP card
- gcc 4.3.3 compiler on Linux Host VM (needed for compatibility w/ (older) filesystem as delivered on MityDSP ARM processor)

I'm following the DSP Hello World Wiki instructions and have done the following:
- installed the most recent MDK (release_2014-01-13.run)on the Linux VM and host Windows machine
- downloaded the source files [arm_main.cpp to Linux VM, main_dsp.cpp to Windows]
- created the Eclipse HelloWorldDSP project with the Build Variables exactly as defined in the Wiki except for:
--> MDK variable, where I used the path /home/mitydsp/MDK_2011-03-31 (I'm assuming that I need to point to the MDK that is compatible with gcc 4.3.3 and the filesystem on the ARM processor?)
- set up the Cross G++ Linker according to the instructions (using "${LIBDSP}" and "${LIBARM}" variables in the linker settings)

When I build, the console displays the following:

  • Internal Builder is used for build ***
    arm-angstrom-linux-gnueabi-g++ -L/home/mitydsp/MDK_2011-03-31/lib/ARM/Debug -oHelloWorldDSP src/arm_main.o ../../../MDK_2011-03-31/lib/ARM/Debug/dsplink.lib -ldsp -lpthread
    src/arm_main.o: In function `main':
    /home/mitydsp/workspace/HelloWorldDSP/Debug/../src/arm_main.cpp:90: undefined reference to `MityDSP::tcIPCOutbound::SendMessage(void
    )'
    collect2: ld returned 1 exit status
    Build error occurred, build is stopped

I've also attempted a build with the Build Variable MDK path set to /home/mitydsp/MDK_2014-01-13 and get

  • Internal Builder is used for build ***
    arm-angstrom-linux-gnueabi-g++ -L/home/mitydsp/MDK_2014-01-13/lib/ARM/Debug -oHelloWorldDSP src/arm_main.o ../../../MDK_2014-01-13/lib/ARM/Debug/dsplink.lib -ldsp -lpthread
    /usr/local/angstrom/arm/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: Dwarf Error: mangled line number section.
    /home/mitydsp/MDK_2014-01-13/lib/ARM/Debug/libdsp.a(ipc_inbound.o): In function `std::list<MityDSP::tcIPCInbound_private::CB_Info, std::allocator<MityDSP::tcIPCInbound_private::CB_Info> >::_M_insert(std::_List_iterator<MityDSP::tcIPCInbound_private::CB_Info>, MityDSP::tcIPCInbound_private::CB_Info const&)':
    ...
    ipc_inbound.cpp:(.text._ZNSt4listIPN7MityDSP12tcIPCHandlerESaIS2_EE8_M_eraseESt14_List_iteratorIS2_E[std::list<MityDSP::tcIPCHandler
    , std::allocator<MityDSP::tcIPCHandler*> >::_M_erase(std::_List_iterator<MityDSP::tcIPCHandler*>)]+0x1c): undefined reference to `std::_List_node_base::_M_unhook()'
    collect2: ld returned 1 exit status
    Build error occurred, build is stopped

I seem to be stumbling a bit with finding the correct combinations of toolchains/target ARM filesystems/MDK releases that work together. Is there a master table somewhere in the documentation or the Wiki that publishes the contents and compatibility of the releases with all of the environments (which toolchain release needs which MDK and filesystem or NAND flash version)? If I need to update the filesystem on the ARM NAND, I may need some help there as I've read through the link "https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Linux_Root_File_System#Flashing-Image-to-NAND" and will likely need some detailed guidance (never flashed a filesystem before).

Thanks,
Doug


Replies (6)

RE: DSP HelloWorld Compile with gcc 4.3.3 - Added by Jonathan Cormier almost 6 years ago

I created a how to for updating an L138 devkit. Let me know if theres any confusing parts.
Updating devkit to latest MDK

RE: DSP HelloWorld Compile with gcc 4.3.3 - Added by Doug Browning almost 6 years ago

Thank you for the filesystem update procedures. I was able to successfully complete steps 1-5 (writing UBL_SPI_MEM.ais, u-boot-ubl.bin, and uImage to flash NOR).
However, in step 6, after many (>10) attempts to tftp the filesystem (mityomap-full.jffs2)to the L138 board, I was unable to complete the file transfer. A couple of times the loading process "hung", the rest resulted in host system crashes (Win7). I tried changing the u-boot tftp block size (to 512 and 2048), but got same result.
I also set up a tftp server on the Win7 host (w/ .jffs2 on host machine in tftp folder) to bypass the VM, but result is the same - system crash. My setup is on an IT-managed network, so that may be an issue (lost UPD packets ?). Each attempt gets part way through the load before crash occurs - once I saw the string "32 MB received" in the serial port window so I assume the communication link is initiated and working up to a point.
Would u-boot parameter settings or mods to the Ubuntu VM tftp server be worth trying? If so what would you suggest?

Thanks,
Doug

RE: DSP HelloWorld Compile with gcc 4.3.3 - Added by Jonathan Cormier almost 6 years ago

Occasionally I see timeouts during the transfer but I haven't seen windows or the vm crash during a tftp transfer.

One thing to try would be to setup a link directly between your computer and the device. No need for a cross over cable. Sometimes if there is high network traffic it can cause the bootloader to timeout. This probably won't stop your computer from dieing however.

RE: DSP HelloWorld Compile with gcc 4.3.3 - Added by Doug Browning almost 6 years ago

Successful tftp transfer of mityomap-full.jffs2 from VM to L138 ARM core! Tried setting the blocksize to 4096 in u-boot (U-Boot > setenv tftpblocksize 4096) and entire file transferred, no hangs or system crashes.

After reboot, serial terminal window shows "Angstrom v2012.05 - Kernal 3.2.0"

Thanks for the help.

Doug

RE: DSP HelloWorld Compile with gcc 4.3.3 - Added by Jonathan Cormier almost 6 years ago

Glad that you got it working. I've never used the block size feature. I'll check out what affect it has on my tftp downloads.

RE: DSP HelloWorld Compile with gcc 4.3.3 - Added by Jonathan Cormier almost 6 years ago

tftp stalls when I set the block size larger than the standard MTU size (1500 - overhead = 1468). According to the source the block size is already set to this max value. To accept fragmented packets the source says to enable CONFIG_IP_DEFRAG which allows the network stack to buffer incomplete packets until it gets the whole message. Unclear if this would improve speed or have any affect on timed out packets.

    (1-6/6)
    Add picture from clipboard (Maximum size: 500 MB)