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.

TMS320C6678: Memory address of 'dataBuffer' in Hyperlink example code has a dependency problem.

Part Number: TMS320C6678
Other Parts Discussed in Thread: MATHLIB,

Tool/software:

Hi, I have a custom board which has two DSPs (c6672 & c6678) connected via hyperlink.

I have successfully tested the hyperlink interface with the example code provided in pdk_c667x_2_0_16.

But when I try to modify the memory address of 'dataBuffer' in the example code, something happens that I can't explain:

If I put 'dataBuffer' on the address 0xD00B_AA00, hyperlink works fine. (cpuTokenExchange)

But if I put 'dataBuffer' on the address 0xD000_0000, hyperlink fails (single write failed).

(I didn't make modifications on the hyperlink example code except for DATA_SECTION of dataBuffer.)

Would you please explain the reason for this?

  • J.H,

    I would have to look into this to see who would be right in answering this question.

    Is it possible that this space is out of the memory-supported range?

    It may be found in the setup section of how the memory range is configured.

  • Thank you for looking into this. I thought this was a simple question regarding Hyperlink address translation (memory mapping).

    And yes, I manually set the memory section for hyperlink (0xD000_0000 ~ 0xDFFF_FFFF) which is memory-supported (DDR3).

    Then I put 'dataBuffer' to this memory section using #pragma DATA_SECTION.

    If I set the memory section from "0xD00B_AA00", hyperlink works fine.

    But setting the memory from "0xD000_0000", hyperlink fails.

  • Hi, can you tell us what SDK package is being used (that contains the pdk_c667x_2_0_16) so we can cross-check?

  • Common settings for both DSP1 (c6672) & DSP2 (c6678)

    - Compiler version: TI v8.3.5

    XDCtools version: 3.60.2.34_core

    c667x PDK 2.0.16

    SYS/BIOS 6.83.0.18

    Please note that DSP2 additionally uses

    c667x OpenMP 2.6.3.00

    DSPLIB C66x 3.4.0.4

    - MATHLIB c66x 3.1.2.4

  • Thanks for the details; however, our original query has not been answered. What SDK package & version is being used here?

    Is it one of the these listed here --> https://www.ti.com/product/TMS320C6678#software-development . If so, can you please specify which one?

    The reason we are asking this --> Since these devices/platforms are old, we need to check the SDK you are referring to and comment on your query.

    Thanks.

  • Oh, sorry that I misunderstood.

    SDK package & version : processor_sdk_rtos_c667x_6_03_00_106.

    I thought that this issue was related to the register settings from the hyperlink example code. (Tx - Rx Address mapping)

  • We can see hyberbus and hyperflash, but we do not see hyperflash. So can you point us to the example you are referring?

  • I am working on the HyperLink peripheral, not hyperbus nor hyperflash.

    I don't even know what hyperbus and hyperflash are. I don't think it is even supported in TMS320C6678 DSP.

    I have copied following files from C:\ti\pdk_c667x_2_0_16\packages\ti\drv\hyplnk\example into my custom project.

    (hyplnkIsr.h, hyplnkLLDCfg.h, hyplnkLLDIFace.h, hyplnkPatCfg.h, hyplnkResource.h /

    hyplnkExample.c, hyplnkIsr.c, hyplnkLLDIFace.c, hyplnkResource.c)

    Then I commented these lines so that I can test "hyplnkExampleCPUTokenExchange" with two DSPs.

    - #define hyplnk_EXAMPLE_LOOPBACK

    - #include "../../InfraDMA/hyplnkInfraDMA.h"

    - #include "../../EDMA/hyplnkEDMA.h"

    And I modified DATA_SECTION for "dataBuffer" so that I can move memory allocation "0xD000_0000" or "0xD00B_AA00".

  • If I modify the parameters of address translation, the result is same.

    For example, I changed following parameters:

    TXAddrOvly.txIgnMask (10 -> 11)

    RXAddrSel.rxSegSel (6 -> 12)

    RXSegVal.rxLenVal (21 -> 27)

  • Thanks for pointing us to the right example to look at. We are getting to understand what you are saying above. However, we still have a few questions:

    - What is the .cfg file being used by your custom project? 

    - Why did you choose 0xD00B_AA00 initially for the dataBuffer, and why are you changing it to 0xD000_0000?

  • 1. I also made a custom .cfg file. For the hyperlink purpose, I added these lines:

    - var hlink = xdc.useModule('ti.drv.hyplnk.Settings');

    - Program.sectMap[".hyplnk_buffer"] = "DDR3_HYPLNK"; //"DDR3_HYPLNK" is also defined in my Platform Package. I modify my Platform Package to move memory allocation for hyplnk_buffer.

    2. I first tested the hyperlink example code without any modification and It went well. In that case, 'dataBuffer' was allocated in 0x8xxxB_AA00 since the original example code has #pragma DATA_SECTION (dataBuffer, '.bss:hyplnkData"). Then I wanted to define the specific memory section for 'dataBuffer' so that DSP1 and DSP2 can share the transparent hyperlink remote memory (which was 0xD000_0000, note that each DSP1 & DSP2 has its own independent DDR3 memory), but it failed. To fix that I tried memory allocation for 0xD00B_AA00, it succeeded. I want to understand why this is happening because I can tell there should be something that I'm missing.

  • Thanks for the details. It was always better to give all the details so that we don't have to go back and forth.  It would be better if you could share the complete .cfg file for us to review and make sure there are no other obvious changes that would conflict with the usage of 0xD000_0000.

    Thanks,

  • I wish I could share the complete .cfg flie or complete CCS project and platform package to make things easier, but unfortunately it is limited because of my company's security policy.

    I was expecting these kind of messages from TI experts.

    1. You need to modify the HyperLink example code (ex. HyperLink remote register settings) to enable the usage of 0xD000_0000.

    2. By testing on the reference design (ex. EVM boards) to reproduce the result, 0xD000_0000 should work as well so you need to look into your .cfg file (or platform package or something else).

    or If you can specify what settings should I find in .cfg file, I can share it (since sharing original code is limited.)

    But I am more skeptical that what kind of .cfg settings can make an access to 0xD00B_AA00, not 0xD000_0000.

  • I was expecting these kind of messages from TI experts.

    Just want to set the expectation here.  This is a pretty old SDK, so we can only support the SDK-provided example code. if you have made modifications to the code and something is not working, we expect you to give us complete information to provide you with suggestions/support.

    Thanks.