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.

How DSP knows that all the packets has been received in EMAC boot mode.

Other Parts Discussed in Thread: TMS320C6474

HI, I need to know how the DSP knows all of the packets of information have been received in EMAC boot mode.

We are using TMS320C6474 and from the bootloader manual (SPRUEC6D) I know that for SRIO boot method, the master will issue a door-bell message to DSP so DSP knows configuration is done.  But in EMAC mode, I didn't see in any way the master tells DSP that configuration is done. 

 

Thanks very much for your reply, 

Shirley

 

 

  • Shirley,

    According to the manual the RX interrupt (routed to interrupt 5) is enabled by the bootloader. The RX packets are processed and moved to boot memory once this interrupt occurs.

  • Aditya: 

    Who will send the interrupt, the master sending EMAC packet?

    And How does the DSP knows which is the last EMAC packet? Is the configuration size for DSP a constant number as FPGA? 

    Also, I read that 16K L2 memory is divided to 10 packet buffers with each holds 1600 byte (from sprug24, Page 12). Does it mean that the configuration packet can only be equal or less than 1600 Bytes? And another question, I don't think 16K is enough to hold the configuration file. 

    Thank you very much for your reply,

    Shirley.

     

  • Shirley,

    The latest boot loader user's guide is:  http://focus.ti.com/lit/ug/spruec6e/spruec6e.pdf

    Section 6.2.2 describes the boot table format and how it works in conjunction with the hex conversion utility.  The end of the boot table is denoted by a zero byte section of the boot table.  When the bootloader (code executed from the internal ROM) sees this end marker, it automatically jumps to the base of L2 and begins execution of the image.  Interrupts are actually generated after each RX packet and handled by the bootloader.  Only when it sees the end marker does it begin execution of the code at L2 base address.

    The 16K L2 memory region that is dedicated for boot is only a temporary storage place for the RX packets.  Essentially, this area is for buffering purposes.  These buffers are recycled so that the image you load can be much bigger than the 16K storage area.  The image is temporarily buffered here and moved by the bootloader code to other L2 addresses.  I'm not sure what the actual image size limit is, but may be able to find out.  If the size limit is too small in L2, you can always do an I2C boot, load a boot configuration table to enable DDR memory, load a boot parameter table for EMAC boot which uses the DDR, then re-enter EMAC boot and send the image.

    Regards,

    Travis

     

  • Hi Travis:

    Thank you for your reply, that answers most of questions.

    Does a Zero byte section mean we give the length field in the UDP header as 0?

    Thanks,

    Shirley

     

     

  • No, The zero-byte secsion is in the payload not in the UDP header.

     

    Thanks,

    Arun.

  • But the payload header only have magic number (0x544B), Opcode (0x01) and sequence number. It doesn't have a length. 

    Do you mean that for the zero-byte section, we still have the header there and then nothing else?

    Thanks,

    Shirley

  • No It is the payload itself. PLease check the boot table description in the user guide to get more info. The 0x00000000 is the termination record in the payload to denote the end of packet. Please let me know if you still need additional clarification.

     

    Thanks,

    Arun.

  • Does it require 1600 byte (the L2 buffer size) for each packet? If there isn't enough data, just fill in 0s? 

    Thanks,

    Shirley

  • Each packet can be upto 1600B.  You should not pad with 0s.  There are some utility programs that will take your .out file and convert it to the right format (.eth) for sending it via ethernet to the DSP.  There is even a PC executable that can be used to send it to the DSP for test purposes.  We will try to locate those and provide a link tomorrow.

     

    Regards,

    Travis