ethernet sample code

for DM6446, ethernet peripheral is controlled by ARM; therefore, you will need to have some software running on the ARM to contorl it.  Since ARM is quite complex, normally most users use ARM with an operating system (WinCE, Linux, Integrity, QNX...).  We provide Linux with our system (it includes ethernet driver); however, if you do not want to use this, you can get other OSes from some of our third parties.  If you let us know our end-goal and why using Linux is not a good option, perhaps we can make a better recommendation.

Just another potential perspective, if you need minimal Ethernet capabilities, such as to load data over a TFTP server than you can probably get by with just booting U-Boot (the Linux boot loader) as opposed to a full Linux kernel. Either way as Juan mentioned you will be leveraging some form of advanced/high level software, everything TI provides directly is Linux related.

actually we have custom board and right now no operating system is running on it.

and we just want to check ethernet via arm...

The easiest way would be to boot something like U-Boot on the board to test the Ethernet, I do not know of any stand alone test programs for the ARM that would exercise the Ethernet. You could take a look at the U-Boot source and strip out just the Ethernet functionality however it would be easier to just boot the standard U-boot.

There are tests available in the Specturm Digital site (http://support.spectrumdigital.com/ ); these test are used to test the EVM from SD; however, I am thinking that if you grab the DM355 target content tests ( DM6446 ones do not include source code), you should be able to easily adapt it for DM6446 on your own board.  FYI, these tests are run via CCS.

I did not mention the SD tests previously due to lack of source, and that they are no longer present on the DM6446 EVM support page, they are still hidden on the site however here. 

Note that the Ethernet test code here is not a standard TCP/IP stack, it only does a loopback with a special connector on the board.

Also note that the DM355 tests that do have source would be entirely different from the DM6446 tests, as the DM355 does not have an on board EMAC (it uses an external EMAC on the EMIFA). The closest would probably be the DM6467 code, though even this would need additional modification as it uses a different EMAC peripheral than the DM6446 (it has a gigabit version).

thanx for your help

Bernie Thompson

In emac_loopback code there is Printf command

can you tell me host is printing these messages via JTAG Or via uart 0

if you are running a CCS project (which it sound like you are), it should print out via JTAG to CCS

r u sure bec as far i know JTAQ cable is used for debuging

for transfering msgs UART PORT is used but i m nt sure

FYI, printf messages normally go to standard output, when booting via u-boot or Linux OS, the standard output becomes UART0; however, when using CCS (no u-boot or Linux running), the standard output becomes CCS window.

Juan is correct, these CCS based examples do not use the UART for standard i/o, everything is done through JTAG and you will get messages in a prompt in CCS. If you wanted it to output to UART you would have to modify the run time support library to handle setting up and writing to the UART.

Also note that the DM355 tests that do have source would be entirely different from the DM6446 tests, as the DM355 does not have an on board EMAC (it uses an external EMAC on the EMIFA). The closest would probably be the DM6467 code, though even this would need additional modification as it uses a different EMAC peripheral than the DM6446 (it has a gigabit version)

i m stuck on Emac test code for DM6446 Where i need to do change code...

plz tell me my DDR2 Is not working can i save that code on DSP memory if yes than how?

jawad said:

plz tell me my DDR2 Is not working can i save that code on DSP memory if yes than how?

You would have to modify your project's memory mapping to use the internal memory space, the ARM should be able to see the DSP internal memory at 0x11800000 for 64KB. In the case of an ARM project you would have to open up your linker command file and change the memory segment to the internal memory and adjust it such that your code/data sections are placed within the internal memory instead of external DDR.

How is your DDR not working, perhaps you need to modify your GEL file?

no actually we have made a custom board and it there is solding issue so that y our DDR is nt working...

we are trying to overcome that problem..

Also note that the DM355 tests that do have source would be entirely different from the DM6446 tests, as the DM355 does not have an on board EMAC (it uses an external EMAC on the EMIFA). The closest would probably be the DM6467 code

can i use same gel file for emac loopback test as it is in this folder

i have also replaced its cmd file and put that cmd file

/*
 *  Linker command file
 *
 */

-l rts32e.lib
-l ..\..\lib\davincihdbsl.lib

-stack          0x00001000      /* Stack Size */
-heap           0x00001000      /* Heap Size */

MEMORY
{           

    L2RAM:    origin = 0x11800000, len = 0x8000
    L1DRAM:    origin = 0x11F04000, len = 0xc000
}


SECTIONS
{
    .text       >       L2RAM
    .stack      >       L1DRAM
    .bss        >       L1DRAM
    .cinit      >       L1DRAM
    .pinit      >       L1DRAM
    .template   >       L1DRAM
    .cio        >       L1DRAM
    .const      >       L1DRAM
    .data       >       L1DRAM
    .switch     >       L1DRAM
    .sysmem     >       L1DRAM
    .far        >       L1DRAM

}
now it come davaind_init but could nt comes out from EMAC loop test?\

i dont know what is problem

jawad said:

can i use same gel file for emac loopback test as it is in this folder

Probably not, as the GEL file will be assuming a DM6467 which has a different memory map (peripherals are at different addresses) which could cause all sorts of problems. There are GEL files specific to the DM6446 on the Spectrum Digital Support page for the DM6446 EVM that would be much more appropriate, the GEL file is not very concerned directly with the EMAC anyway, it is primarily defining the memory mapping and setting up the external memory interfaces and clocks.

emac loopback test is working

thanx alot