TDA4VM: Access to On-the-fly eye and bathtub curve diagramming data

any news / updates on the topic above?

Thank you Kyle, we will have a try.

From your answer i assume, that (even if you have no tool today) you will not have a tool for PCIe, correct?

Tool will be shared via customer share server 

Cornelius,

I received feedback from Karim: 

Alpha tool version received, but issues with absolute paths in library (pattern_gen lib) lead to a exception during execution. Source Code requested for libraries.

If you are trying to rebuild the executable binary, you shouldn't need source for libraries to fix an absolute path issue.

There are no “paths” in the test code and the existing binary should work fine if they are using UART0. Can you give more details on what you're seeing?

Thanks,

Kyle

Hi Kyle,

The function pat_gen_wc_isi_sso  from the pattern_gen_lib buffers its pattern in the memory beginning at 0x000000000. It works fine and the pattern is visible until the address 0x00008000 is reached, which causes an exception. It seems that our Jacinto has no usable memory there unlike your uC used for testing. Therefore we’d need the source code to adjust the location where the pattern is stored.

Regards,

Cornelius

Cornelius,

Can you please list the exact part number you are using?

Can you please provide exact detailed steps of how you are executing the program, starting with powering on your PCB (and what code gets executed, if any)?

Thanks,
Kevin

Kevin,

The exact part number of our Jacinto is TDA4VM88TGBALFRQ1.

The program execution is the same as in your example provided. After powerup and the entry to main() at first UART is configured, then the tool info is printed with the function jacinto7_ddrss_tools_header(). Here an output via UART is visible. Then the function jacinto7_ddrss_tools_get_ddr_config() is called and also runs correctly. Next the function jacinto7_ddrss_tools_marginAnalysis_config() is called, which works until it internally calls the library funtion pat_gen_wc_isi_sso(), where the exception occurs.

Note that until this point everything runs correctly and that all the expected outputs are visible via UART.

We've analyzed pat_gen_wc_isi_sso() in Assembler with a Debugger and it starts writing a pattern to the memory beginning at address 0x00000000. After multiple iterations, the address space from 0x00000000 to 0x00007FFFF is filled with a clearly visible pattern and the code runs fine until this point.

But as soon as 0x00008000 is addressed, an exception occurs.

From our point of view, the easiest solution would be if we had the source code of the pattern_gen_lib, so we could change the location where the pattern is stored.

Regards,

Cornelius

Cornelius,

The test code does not hard code where the pattern is stored internal to the TDA4. It makes a call to aligned_alloc to determine where the start address is located.

This should be inside of the MSMC RAM (0x70000000 start address), which is entirely dedicated to the heap and defined in the linker command file (<BASE_DIR>/build/r5/K3-J7.cmd) included with the CCS project files. 

However, if the MSMC RAM is configured as cache by some external code, then this could easily cause a problem.

What I was trying to ask previously is, what code is being executed on your board prior to loading this code? This tool does not configure DDR, so how is DDR being configured? (ex: through a GEL file, through u-boot, through RTOS SBL, etc.).

Regards,
Kevin

Hi Kevin,

I'm a colleague of Cornelius and currently working on this issue.

The startup code was provided to us by TI (its version is sdk-linux-j7-evm-07_03_00_05 and u-boot is u-boot-2020.01+gitAUTOINC+2781231a33-g2781231a33). We don’t use the GEL script to configure the DDR, but rebuilt its functionality in C code before the entry into jacinto7_ddrss_tools_header(). The GEL function J721E_Configure_MCU_R5_RAT() writes to several addresses and we do the same.

Regards,

Leonhard

Leonhard,

Leonhard Augart said:

We don’t use the GEL script to configure the DDR, but rebuilt its functionality in C code before the entry into jacinto7_ddrss_tools_header(). The GEL function J721E_Configure_MCU_R5_RAT() writes to several addresses and we do the same.

To clarify, 

• You do not use ANY GELs, including the GELs provided in the software package?
• Which GEL script(s) did you add to the software package binary (the DDR initialization or the J721E_Configure_MCU_R5_RAT function)?
  
  • If you added the J721E_Configure_MCU_R5_RAT function to the software package binary, did you also modify the linker command file?
  • If you added the DDR initialization to the software package binary, did the DDR initialization occur twice? (once from u-boot and once from the binary)?

Leonhard Augart said:

The startup code was provided to us by TI (its version is sdk-linux-j7-evm-07_03_00_05 and u-boot is u-boot-2020.01+gitAUTOINC+2781231a33-g2781231a33).

Is it a correct understanding that u-boot is configuring the DDR interface?

At what point do you load the software binary?

If you are loading the binary after Linux has fully booted, can you please try loading the binary before Linux is launched (after u-boot loads)?

Regards,
Kevin

Hello Kevin,

sorry for the delayed answer. May colleague is on vacation, and I just noticed today that there is a new answer on this topic.

First: yes, it is correct that we do not use the GEL files.

But there was a misunderstanding in Leonhards response regarding the boot process: our startup code is not based on sdk-linux-j7-evm-07_03_00_05, but on ti-processor-sdk-rtos-j721e-evm-07_03_00_07 (resp. pdk_jacinto_07_03_00_29).
Accordingly, we do not use U-Boot, but the TI RTOS SBL from the PDK.

In the application which integrates the DDRS tool library, we call at the beginning the Board_init() function of the PDK to do some more low level initializations, including DDR. MSMC is not configured as cache, it is located ad 0x70000000.

Kevin S said:

Which GEL script(s) did you add to the software package binary (the DDR initialization or the J721E_Configure_MCU_R5_RAT function)?

• If you added the J721E_Configure_MCU_R5_RAT function to the software package binary, did you also modify the linker command file?
• If you added the DDR initialization to the software package binary, did the DDR initialization occur twice? (once from u-boot and once from the binary)?

We looked at the GEL files and then did the same RAT settings in our code via CSL function CSL_ratConfigRegionTranslation from the PDK. We also checked with the debugger that the settings are written correctly and that the address translation works.

Unfortunately I don't have the code at hand, but if I remember it correctly, we also checked the linker script. 

Anyway, what exact modification in the linker script would be needed? Our linker script is also based on the PDK with all sections allocate there. Are there some special sections that need to be set for the DDR tool?

Regards

Thomas

Kevin

As Thomas wrote, we do not use the GEL files and neither U-Boot. Also, we verified the RAT is configured correctly. We have checked our linker script and can confirm that it contains all your sections. Are there any further modifications necessary?

We checked the MSMC RAM beginning at 0x70000000 and no write occurs to it in pat_gen_wc_isi_sso(). Again, the pattern is visible beginning at address 0x00000000 and then the exception occurs. Would it be possible, that you provide the source code of this library to us? This way we could debug and further analyze the issue.

Regards

Leonhard

Hi Thomas, Leonhard,

pat_gen_wc_isi_sso first tries to allocate memory space. I am not confident that is occurring correctly (as hinted in prior post).

Rather than call "pat_gen_wc_isi_sso", please edit the code to make the following call: buff_src = aligned_alloc(64, 487872);

After making the modification and executing the new binary, please record the location of buff_src after the new line executes. If set to "0x00000000", then this is clearly an issue - it should be near 0x70000000 (in the MSMC SRAM).

I believe aligned_alloc should return a null pointer (0x00000000) on failure (this seems to match what is occurring in your system), but I have not yet added in checks to exit on failure. 

My prior assumption was that MSMC RAM is configured as cache. Thus, can you also please record the value in the MSMC_CACHE_CTRL register (address 0x6E001000) either before or after you run the tool?

Regards,
Kevin

Hi Kevin,

We have tested buff_src = aligned_alloc(64, 487872); and buff_src indeed gets set to 0.

Also, we've recorded the value of MSMC_CACHE_CTRL before and after code execution. Both times its content was 0.

Kind regards,

Leonhard

Hi Leonhard,

Thanks for this information. Can you confirm whether you can read / write to the MSMC SRAM memory space (0x70000000)? I assume so, but just want to confirm.

Regards,
Kevin

Also, can you let me know what compiler version you are using when re-building?

Thanks,

Kevin

Hi Kevin,

the compiler version we use is ti-cgt-arm_20.2.2.LTS. And yes, we can write to and read from the MSMC SRAM memory space.

Regards,

Leonhard

Hi Leonhard,

I will send you a friend request / private message with proposed next steps.

Regards,
Kevin