TMS320DM8148: syslink driver

Let me rephrase

We are using TMS320DM148 for a few years. The firmware download to the DSP is done from the CortexA8 using the syslink driver and linux operating system,

Linux version 2.6.37

SysLink version 2.20.02.20

SysLink module created on Date:Sep 11 2014 Time:15:48:44

As long as we used Code Generation Tools version 7.3.4 we had no problems with download. Now we want to migrate to Code Generation Tools version 7.6.0. When performing the same procedure with firmware compiled with CGT 7.6.0 we’ve noticed that always during download there are some cases that data is not written correctly to DSP memory. In all cases we have noticed the failure is in the last word of a block in which instead of the value ‘0’ there is an arbitrary value.   Is there an explanation to this problem, is it a known problem, is there a solution or workaround ?

We also encountered problems with code size when migrating to this CGT please see more details in https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1028395/tms320dm8148-transition-from-cgt-7-3-4-to-cgt-7-6-0-for-tms320dm8148/3805835#3805835

Hey Team, 

Could you please help Doron with the DM814X ? 

Kind regards,

Eyal

Eyal,

Has this question not been answered by this post?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1028395/tms320dm8148-transition-from-cgt-7-3-4-to-cgt-7-6-0-for-tms320dm8148

Regards

Karthik

no this was not answered by the post

The connected issue is also talking about migration from CGT 7.3.4 to 7.6.0 but it focuses on the size of the compilation output file that was significantly decreased.

This question was indeed answered in the connected post but it does not answer the current question

Hi Doron,

Any reasons for picking/using 7.6.0 CGT? I do not see this release on the public Code Generation Tools Downloads page, I only see 7.3.x and 7.4.x in the 7.x release stream, which have more stable releases done later than the 7.6.x release. The various components in the stack - SYS/BIOS, XDC, IPC, SysLink releases are only cross-verified against some known compilers. I do not see any product using a 7.6.x CGT.

What image format are you using? If you are using ELF, can you give the output of "readelf -l" command on both the versions and which address is getting affected from your ELF files?

doron gabbay said:

to 7.6.0 this resulted in one of the blocks instead of having zero at the last word location,
we are having the data of 0xA9690000 at that location, the data can varies.

Can you provide some more clarifications on this?

- Is it only on one of the blocks or is it on all blocks?

- Is the last word part of the ELF loadable section area (address is part of FileSiz and not MemSiz from readelf -l output)?

ProcMgr only loads the contents that have a positive FileSiz and zero initializes any memory that is > FileSiz and < MemSiz. If your address falls into this area, then that section is expected to be initialized by the C Runtime code on the firmware-side. So, please look through your map files and compare the TI_CInit tables. The C Runtime initialization logic comes from the Compiler.

regards

Suman  

We are using CGT 7.6.0 for a few years since starting the development of our C6678 based product. We wish to use this CGT now on other targets since we verified many of our new modules with this CGT version 

With this CGT we also use

on C6678:

bios version 6_41_04_54

xdc version 3_30_06_67

xdais version 7_22_00_03

SYSLINK_VER 2_20_02_20

on DM8148

bios version 6_33_05_46

xdc version 3_23_03_53

xdais version 7_22_00_03

SYSLINK_VER 2_20_02_20

Should there be any problem with this set of tools on any of the products?

Hi Doron,

Please see the various release download pages for each of SYS/BIOS, XDC and IPC. There are some recommended versions to go with each version that are well tested as it is not possible to test every combination. It looks like you have been using these for quite sometime, and they look compatible, so you should be ok. I see BIOS 6.33.05.46 was originally recommended to be used with XDC 3.23.02.47, and you are using the next XDC version. Each of the tools Release notes do have compatibility notes as well.

Here's the release notes for XDC 3.23.03.53 for example,

https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/3_23_03_53/exports/xdctools_3_23_03_53_release_notes.html

Product download links:

SYS/BIOS: https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/

XDC: https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/

IPC: https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/

Please provide the answers for the other questions.

regards

Suman

"What image format are you using? If you are using ELF, can you give the output of "readelf -l" command on both the versions and which address is getting affected from your ELF files?"

- we are using elf format 
- attached file are the readelf file requested 
- the affected address is 0x8F293A20 the start address of the block is 0x8F291AE0    and the bloack size is 8000 bytes (2000 32bit size)

"- Is it only on one of the blocks or is it on all blocks?"

• One block

"is the last word part of the ELF loadable section area"
        the last word is part of the elf file

"ProcMgr only loads the contents that have a positive FileSiz and zero initializes any memory that is > FileSiz and < MemSiz. If your address falls into this area, then that section is expected to be initialized by the C Runtime code on the firmware-side. So, please look through your map files and compare the TI_CInit tables. The C Runtime initialization logic comes from the Compiler."

• When loading using the jtag every thing is OK

dorong@il-dorong-pc MINGW64 /d/Dsp724/Gen5/Ac504/Out ((0e5743f...))
$ readelf -l AC5042_EthernetOnly.out

Elf file type is EXEC (Executable file)
Entry point 0x8f2a1000
There are 32 program headers, starting at offset 12920744

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000038 0x10800000 0x10800000 0x00000 0x09e68 RW  0x8
  LOAD           0x000040 0x10809e80 0x10809e80 0x0ac20 0x0ac20 R E 0x20
  LOAD           0x00ac60 0x10814aa0 0x10814aa0 0x00000 0x032cc RW  0x8
  LOAD           0x00ac60 0x10814aa0 0x10814aa0 0x00000 0x00da0 RW  0x8
  LOAD           0x00ac60 0x10814fb0 0x10814fb0 0x00000 0x00778 RW  0x8
  LOAD           0x00ac60 0x10814fb0 0x10814fb0 0x00000 0x00558 RW  0x8
  LOAD           0x00ac60 0x10814fb0 0x10814fb0 0x00000 0x00e00 RW  0x4
  LOAD           0x00ac60 0x10815840 0x10815840 0x00000 0x00928 RW  0x10
  LOAD           0x00ac60 0x10817d80 0x10817d80 0x00000 0x01010 RW  0x20
  LOAD           0x00ac60 0x10818da0 0x10818da0 0x011a0 0x011a0 R E 0x20
  LOAD           0x00be00 0x8f000000 0x8f000000 0xd52c0 0xd52c0 R E 0x80
  LOAD           0x0e10c0 0x8f0d52c0 0x8f0d52c0 0x00000 0xc5c28 RW  0x8
  LOAD           0x0e10c0 0x8f19aee8 0x8f19aee8 0x00114 0x00118 RW  0x8
  LOAD           0x0e1800 0x8f19b000 0x8f19b000 0x539c0 0x539c0 RW  0x800
  LOAD           0x1351c0 0x8f1ee9c0 0x8f1ee9c0 0x39180 0x39180 R E 0x20
  LOAD           0x16e340 0x8f227b40 0x8f227b40 0x5ccc0 0x5ccc0 RWE 0x20
  LOAD           0x1cb000 0x8f284800 0x8f284800 0x0f21e 0x0f21e R   0x800
  LOAD           0x1da220 0x8f293a20 0x8f293a20 0x00060 0x00060 RW  0x8
  LOAD           0x1da280 0x8f293a80 0x8f293a80 0x00000 0x05580 RW  0x80
  LOAD           0x1da280 0x8f299000 0x8f299000 0x042c3 0x042c3 RW  0x8
  LOAD           0x1de544 0x8f29d2c4 0x8f29d2c4 0x0126c 0x0126c R   0x4
  LOAD           0x1df7b0 0x8f29e530 0x8f29e530 0x00000 0x01008 RW  0x4
  LOAD           0x1df7b0 0x8f29f538 0x8f29f538 0x00038 0x00038 RW  0x4
  LOAD           0x1df7e8 0x8f29f570 0x8f29f570 0x00028 0x00028 R   0x8
  LOAD           0x1df810 0x8f29f598 0x8f29f598 0x00000 0x01000 RW  0x8
  LOAD           0x1df810 0x8f2a0598 0x8f2a0598 0x00010 0x00010 RW  0x8
  LOAD           0x1df880 0x8f2a0600 0x8f2a0600 0x00880 0x00880 RW  0x80
  LOAD           0x1e0400 0x8f2a1000 0x8f2a1000 0x00200 0x00200 R E 0x400
  LOAD           0x1e0800 0x8f2a1400 0x8f2a1400 0x0004c 0x0004c R   0x400
  LOAD           0x1e0850 0x8ffff900 0x8ffff900 0x006b8 0x006b8 RW  0x8
  LOAD           0x1e0f08 0x90000000 0x90000000 0x00000 0x3000000 RW  0x8
  DYNAMIC        0x1e0f08 0x00000000 0x00000000 0x000b0 0x00000 RW  0

 Section to Segment mapping:
  Segment Sections...
   00     .InternalData
   01     .InternalCode .GROUP2
   02     OsW1 VfdSwitchVar FaxRelayVar DataPumpVar DataPumpWA VfdSwitchWA FaxBypassWA FaxRelayWA
   03     VfdSwitchVar FaxRelayVar DataPumpVar VfdSwitchWA FaxBypassWA
   04     VfdSwitchWA FaxBypassWA
   05     FaxBypassWA
   06     DataPumpVar VfdSwitchWA FaxBypassWA FaxRelayWA
   07     DataPumpWA
   08     .L1D_ram
   09     .GROUP_SerialPort .HPIInternalCode .host_int
   10     .External1
   11     .ExternalData
   12     HpiMap .far.1
   13     .OS_STUFF .fardata.1 .far.2
   14     .SharedCode
   15     .External .G729 .fardata.2 .fardata.3 .far.3
   16     .constSection
   17     .fardata.4
   18     DebugVars
   19     .fardata.5
   20     .switchSection
   21     __TI_STATIC_BASE:g729_enc __TI_STATIC_BASE:g729_dec __TI_STATIC_BASE
   22     NEARDATA
   23     RODATA
   24     .stack
   25     .data_AudioConf
   26     .modified_data .ExternalTables
   27     .vecs
   28     ti_sdo_ipc_init
   29     .ProgramCrcTableSect
   30     systemHeap
   31     .text .bss .neardata .rodata .cinit .init_array .data .c6xabi.exidx .c6xabi.extab .text .cinit .data .far .fardata

dorong@il-dorong-pc MINGW64 /e/SF_no_function/Dsp721_43/Gen5/ac504/device ((5da8600...))
$ ls
Ac5042256.cmd           gl_FixOp.h        memory.h           restartApc.vbs
configuro/              global.h          NMAKE.EXE*         SerialPort.c
debug.dat               host_cfg.h        PacketsTxRx.h      SerialPort.h
Device.c                HpiPacketsTxRx.c  Peripherals.c      Template.h
Device.h                MainDsp.c         Peripherals.h      Utils.asm
Device.mak              makefile          ProgramCrcTable.c
Dsp.cfg                 Mcbsp_Driver.c    Project.mak
EmptyProgramCrcTable.c  Mcbsp_Driver.h    ProjectEnv.bat

dorong@il-dorong-pc MINGW64 /e/SF_no_function/Dsp721_43/Gen5/ac504/device ((5da8600...))
$ cd ..

dorong@il-dorong-pc MINGW64 /e/SF_no_function/Dsp721_43/Gen5/ac504 ((5da8600...))
$ cd out

dorong@il-dorong-pc MINGW64 /e/SF_no_function/Dsp721_43/Gen5/ac504/out ((5da8600...))
$ ls
AC5042_EthernetOnly.hex  AC5042AE3.721.64  AC5042temp.map
AC5042_EthernetOnly.out  AC5042AE3.724.12  server_dsp.xe674

dorong@il-dorong-pc MINGW64 /e/SF_no_function/Dsp721_43/Gen5/ac504/out ((5da8600...))
$ readelf -l AC5042_EthernetOnly.out

Elf file type is EXEC (Executable file)
Entry point 0x8f29b400
There are 32 program headers, starting at offset 12625036

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000038 0x10800000 0x10800000 0x00000 0x09e68 RW  0x8
  LOAD           0x000040 0x10809e80 0x10809e80 0x0b3a0 0x0b3a0 R E 0x20
  LOAD           0x00b3e0 0x10815220 0x10815220 0x00000 0x032cc RW  0x8
  LOAD           0x00b3e0 0x10815220 0x10815220 0x00000 0x00da0 RW  0x8
  LOAD           0x00b3e0 0x10815730 0x10815730 0x00000 0x00778 RW  0x8
  LOAD           0x00b3e0 0x10815730 0x10815730 0x00000 0x00558 RW  0x8
  LOAD           0x00b3e0 0x10815730 0x10815730 0x00000 0x00e00 RW  0x4
  LOAD           0x00b3e0 0x10815fc0 0x10815fc0 0x00000 0x00928 RW  0x10
  LOAD           0x00b3e0 0x10818500 0x10818500 0x00000 0x01010 RW  0x20
  LOAD           0x00b3e0 0x10819520 0x10819520 0x00c20 0x00c20 R E 0x20
  LOAD           0x00c000 0x8f000000 0x8f000000 0xd4e40 0xd4e40 R E 0x80
  LOAD           0x0e0e40 0x8f0d4e40 0x8f0d4e40 0x00000 0xc5c28 RW  0x8
  LOAD           0x0e0e40 0x8f19aa68 0x8f19aa68 0x001bc 0x001c0 RW  0x8
  LOAD           0x0e1000 0x8f19ac28 0x8f19ac28 0x003d8 0x003d8 RW  0x8
  LOAD           0x0e1800 0x8f19b000 0x8f19b000 0x539c0 0x539c0 RW  0x800
  LOAD           0x1351c0 0x8f1ee9c0 0x8f1ee9c0 0x33e00 0x33e00 R E 0x20
  LOAD           0x168fc0 0x8f2227c0 0x8f2227c0 0x5c840 0x5c840 RWE 0x20
  LOAD           0x1c5800 0x8f27f000 0x8f27f000 0x0f22a 0x0f22a R   0x800
  LOAD           0x1d4a30 0x8f28e230 0x8f28e230 0x00050 0x00050 RW  0x8
  LOAD           0x1d4a80 0x8f28e280 0x8f28e280 0x00000 0x05580 RW  0x80
  LOAD           0x1d4a80 0x8f293800 0x8f293800 0x0404b 0x05058 RW  0x8
  LOAD           0x1d8acc 0x8f298858 0x8f298858 0x00038 0x00038 RW  0x4
  LOAD           0x1d8b08 0x8f298890 0x8f298890 0x00028 0x00028 R   0x8
  LOAD           0x1d8b30 0x8f2988b8 0x8f2988b8 0x00000 0x01000 RW  0x8
  LOAD           0x1d8b30 0x8f2998b8 0x8f2998b8 0x00fb0 0x00fb0 R   0x4
  LOAD           0x1d9ae0 0x8f29a868 0x8f29a868 0x00010 0x00010 RW  0x8
  LOAD           0x1d9b00 0x8f29a880 0x8f29a880 0x00880 0x00880 RW  0x80
  LOAD           0x1da400 0x8f29b400 0x8f29b400 0x00200 0x00200 R E 0x400
  LOAD           0x1da800 0x8f29b800 0x8f29b800 0x0004c 0x0004c R   0x400
  LOAD           0x1da850 0x8ffff900 0x8ffff900 0x00694 0x00694 RW  0x8
  LOAD           0x1daee8 0x90000000 0x90000000 0x00000 0x3000000 RW  0x8
  DYNAMIC        0x1daee8 0x00000000 0x00000000 0x000b0 0x00000 RW  0

 Section to Segment mapping:
  Segment Sections...
   00     .InternalData
   01     .InternalCode .GROUP2
   02     OsW1 VfdSwitchVar FaxRelayVar DataPumpVar DataPumpWA VfdSwitchWA FaxBypassWA FaxRelayWA
   03     VfdSwitchVar FaxRelayVar DataPumpVar VfdSwitchWA FaxBypassWA
   04     VfdSwitchWA FaxBypassWA
   05     FaxBypassWA
   06     DataPumpVar VfdSwitchWA FaxBypassWA FaxRelayWA
   07     DataPumpWA
   08     .L1D_ram
   09     .GROUP_SerialPort .HPIInternalCode .host_int
   10     .External1
   11     .ExternalData
   12     HpiMap .far.1
   13     .fardata.1 .far.2
   14     .OS_STUFF .fardata.2
   15     .SharedCode
   16     .External .G729 .fardata.3 .far.3
   17     .constSection
   18     .fardata.4
   19     DebugVars
   20     __TI_STATIC_BASE:g729_enc __TI_STATIC_BASE:g729_dec __TI_STATIC_BASE .fardata.5
   21     NEARDATA
   22     RODATA
   23     .stack
   24     .switchSection
   25     .data_AudioConf
   26     .modified_data .ExternalTables
   27     .vecs
   28     ti_sdo_ipc_init
   29     .ProgramCrcTableSect
   30     systemHeap
   31     .text .bss .neardata .rodata .cinit .init_array .data .text .cinit .data .far .fardata

dorong@il-dorong-pc MINGW64 /e/SF_no_function/Dsp721_43/Gen5/ac504/out ((5da8600...))
$

Hi Doron,

What is your definition of block? I see the address 0x8f293a20 as the beginning of the following program segment and not the end. This segment corresponds to ".fardata.4" section. It is preceded by the ".constSection" in both cases, and both of these segments should have been memcopied as is.

LOAD           0x1da220 0x8f293a20 0x8f293a20 0x00060 0x00060 RW  0x8

Can you also give the TI_CInit_Tables from your map files for both cases?

regards

Suman

Hi Suman

we do not have the TI_Cint_Tables in the map file 

at that area please see the picture

Regards

Doron Gabbay

Hi Doron,

I did not give out the exact name before. I don't have a C67 reference map file, but please look for the .cinit section and something similar to __TI_cinit_table in your map file.

I am confused about "last word of a block" vs the address you mentioned which is the beginning of the .fardata.4 section.

regards

Suman

This is what we have

Hi Doron,

Interesting, and does this look the same with 7.3.4 as well?

regards

Suman

Hi Doron,

I am guessing the output with 7.3.4 also looks the same based on the readelf output files.

If the corrupted word is indeed the beginning of the .fardata.4 section, it is strange, since the memcpy should directly be copying the 0x60 bytes as is. 

Can you try one experiment, please force an alignment of 0x40 for .fardata.4 section so that it doesn't start right away after the .constSection?

LOAD 0x1cb000 0x8f284800 0x8f284800 0x0f21e 0x0f21e R 0x800
LOAD 0x1da220 0x8f293a20 0x8f293a20 0x00060 0x00060 RW 0x8

The working case has an additional word (6 bytes actually) in between the two, and I want to rule out this possibility. 

regards

Suman

on version 7.3.4 is the same as 7.6.0 as shown above 

it is already aligned for 0x80

Hi Doron,

I see ".fardata" and ".fardata.x" sections as well where x = 1, 2, 3, 4, 5 from your readelf output, which are split into different segments.

.fardata doesn't have anything by itself.

regards

Suman

Hi
what more can I do at my part to resolve this issue

Hi Doron,

Were you able to run the above experiment? 

I can only provide some suggestions, as I do not have the relevant platform and SysLink product is quite old with no active releases.

FWIW, if it was an issue in generic ProcMgr code, then it should have popped up at some other places as well.

regards

Suman

Hi Anna

I have made alignment of 0x40 as you requested but this resulted in the same problem

Please remember that the problem is not on the DSP but on the ARM cortex

Best Regard 

Doron

Hi Doron,

OK, thanks for checking. I have looked through the code again, and compared it to a slightly newer version as well, but I could not find any obvious bug in the loader code.

The particular segment is a straight memcpy segment, so it is highly unlikely there is an issue there.

At this point, I can only suggest that loader code needs to be debugged using a JTAG, and see when the word is being written wrong.  

regards

Suman

Hi Anna
if I would to provide you with the hex file and exact address location of the problem
will that help ?

Hi Doron,

The readelf -l output you provided previously gave me most of the information I need. Anyway, do provide the hex file. Let me see if I can glean any additional information from it.

regards

Suman 

Hi Suman

I adding the hex file "AC5042_EthernetOnly.hex" for you to be able to analyze AC5042_EthernetOnly.txt

please rename the txt to hex

the problematic address is 0x8f2949fc

Hi Doron,

Just to confirm that this hex dump is of your ELF file?

I would recommend you to single step the SysLink ProcMgr driver loader code using JTAG to debug this issue further.

regards

Suman

Suman Anna said:

Just to confirm that this hex dump is of your ELF file?

• yes it is
  as I said, at the address I provided the value is zero.
  and i can also see it when i have loaded directly this file using the jtag.
  but when this file is loaded from the cortex core using the syslink
  the value of at the address provided changes.
  
  Regards
  Doron G

Hi Doron,

Thanks for confirming. I will see what additional information I can glean.

I still highly recommend you to debug the Loader code though since you already have JTAG access.

Also, is it possible for you to try a newer compiler version like the latest on the 7.4.x stream?

regards

Suman

Hi
i have already tried a newer version but this did not help
the problem is not on the DSP side but on loading from the Cortex core to the DSP memory

Regards 
Doron G