• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 481 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C6472 Shared Memory doesn't work with a Linux build

Andrey56137
Intellectual 370 points
Other Parts Discussed in Thread: CCSTUDIO

Fullscreen 8816.Linux_Makefile.txt Download 
# Converted Automatically from a CCS makefile into Linux make file 
#################################################################### 
############# Copyright (C) Signalogic,2010 ######################## 
#################################################################### 
################################################################################
# Automatically-generated file. Do not edit!
################################################################################



EMPTY := 
SPACE := $(EMPTY) $(EMPTY)

ORDERED_OBJS += \
$(GEN_CMDS_QUOTED) \
./tsc_h.obj \
./sample_sig_func_2.obj \
./sample_sig_func_1.obj \
./main.obj \
./func_task_2.obj \
./func_task_1.obj \
-llibc.a \
../Conv_Biosv6.cmd \

-include ../makefile.init

RM := rm -rf
RMDIR := rm -rf

# All of the sources participating in the build are defined here
-include sources.mk
-include subdir.mk
-include objects.mk

ifneq ($(MAKECMDGOALS),clean)
ifneq ($(strip $(S62_DEPS)),)
-include $(S62_DEPS)
endif
ifneq ($(strip $(ASM_DEPS)),)
-include $(ASM_DEPS)
endif
ifneq ($(strip $(C55_DEPS)),)
-include $(C55_DEPS)
endif
ifneq ($(strip $(S_UPPER_DEPS)),)
-include $(S_UPPER_DEPS)
endif
ifneq ($(strip $(C++_DEPS)),)
-include $(C++_DEPS)
endif
ifneq ($(strip $(S_DEPS)),)
-include $(S_DEPS)
endif
ifneq ($(strip $(CC_DEPS)),)
-include $(CC_DEPS)
endif
ifneq ($(strip $(C64_DEPS)),)
-include $(C64_DEPS)
endif
ifneq ($(strip $(CPP_DEPS)),)
-include $(CPP_DEPS)
endif
ifneq ($(strip $(S64_DEPS)),)
-include $(S64_DEPS)
endif
ifneq ($(strip $(CXX_DEPS)),)
-include $(CXX_DEPS)
endif
ifneq ($(strip $(C67_DEPS)),)
-include $(C67_DEPS)
endif
ifneq ($(strip $(S67_DEPS)),)
-include $(S67_DEPS)
endif
ifneq ($(strip $(S43_DEPS)),)
-include $(S43_DEPS)
endif
ifneq ($(strip $(C62_DEPS)),)
-include $(C62_DEPS)
endif
ifneq ($(strip $(C43_DEPS)),)
-include $(C43_DEPS)
endif
ifneq ($(strip $(C??_DEPS)),)
-include $(C??_DEPS)
endif
ifneq ($(strip $(ASM_UPPER_DEPS)),)
-include $(ASM_UPPER_DEPS)
endif
ifneq ($(strip $(OPT_DEPS)),)
-include $(OPT_DEPS)
endif
ifneq ($(strip $(S??_DEPS)),)
-include $(S??_DEPS)
endif
ifneq ($(strip $(S55_DEPS)),)
-include $(S55_DEPS)
endif
ifneq ($(strip $(C_DEPS)),)
-include $(C_DEPS)
endif
ifneq ($(strip $(SA_DEPS)),)
-include $(SA_DEPS)
endif
ifneq ($(strip $(C_UPPER_DEPS)),)
-include $(C_UPPER_DEPS)
endif
endif

-include ../makefile.defs

# Add inputs and outputs from these tool invocations to the build variables 

# All Target
all: Conv_Biosv6.out

# Tool invocations
Conv_Biosv6.out: $(GEN_CMDS) $(CMD_SRCS) $(OBJS)
	@echo 'Building target: $@'
	@echo 'Invoking: Linker'
	/opt/TI/C6000CGT7.0.3/bin/cl6x -mv64+ -g -O1 --define=_EVMC6472 --define=_BIOS --diag_warning=225 -z -mConv_Biosv6.map --warn_sections -i/opt/TI/C6000CGT7.0.3/lib -i/opt/TI/C6000CGT7.0.3/include --reread_libs --rom_model -o Conv_Biosv6.out $(ORDERED_OBJS)
	@echo 'Finished building target: $@'
	@echo ' '

# Other Targets
clean:
	-$(RM) $(GEN_CMDS__QTD)$(GEN_SRCS__QTD)$(C6000_EXECUTABLE_OUTPUTS__QTD)$(GEN_MISC_FILES__QTD)$(GEN_OPTS__QTD) Conv_Biosv6.out
	-$(RM) ./func_task_1.obj .\func_task_2.obj .\main.obj .\sample_sig_func_1.obj .\sample_sig_func_2.obj .\tsc_h.obj 
	-$(RM) ./tsc_h.pp 
	-$(RM) ./func_task_1.pp .\func_task_2.pp .\main.pp .\sample_sig_func_1.pp .\sample_sig_func_2.pp 
	-$(RMDIR)$(GEN_MISC_DIRS__QTD)
	-@echo ' '

.PHONY: all clean dependents
.SECONDARY:

-include ../makefile.targets

Hello,

I am trying to build a program where different cores will read/write an area of shared memory (from the .mpa file, it's called SL2RAM and starts at 0x00200000). This way, the cores can communicate. I built a sample under CCS v4.2 for Win XP, CGT 7.0.3, in which one core stores a value to a shared variable, and another core reads from it (in sequential order, so there are no access conflicts). The output I get when running on the EVM C6472 board is something like:

Core 0, writing memory at 271500, value = 5

Core 1, reading memory at 271500, value = 5

Now, I tried to build this program under Linux (Ubuntu, using command-line tools only). The purpose is to automate the whole process to be able to generate executable file in Linux without the need for CCS. I installed TI's CGT, XDC tools, and DSP/BIOS package, Linux versions. I had to change many things, mainly paths from Windows to Linux in the Makefile, subdir.mk, and other files. I generated the .out file successfully and was able to see some output similar to when I was running this on Windows. However, now the message was

Core 0,writing memory at 271500, value = 5

Core 1, reading memory at 271500, value = 0

So, it appears that one core cannot see what the other stored in shared memory, or they are out of sync somehow. It's very surprising to me, since the code for Windows and Linux is the same, and if there were some errors with Linux CGT, I expected the build to fail. So, is there anything else I should do under Linux to enable shared memory? Or is this a known issue Linux CGT issue?

I am attaching the Windows and Linux Makefile versions for comparison.

Fullscreen 2474.Win_Makefile.txt Download 
################################################################################
# Automatically-generated file. Do not edit!
################################################################################

SHELL = cmd.exe

EMPTY := 
SPACE := $(EMPTY) $(EMPTY)

ORDERED_OBJS += \
$(GEN_CMDS_QUOTED) \
"./tsc_h.obj" \
"./sample_sig_func_2.obj" \
"./sample_sig_func_1.obj" \
"./main.obj" \
"./func_task_2.obj" \
"./func_task_1.obj" \
-l"libc.a" \
"../Conv_Biosv6.cmd" \

-include ../makefile.init

RM := DEL /F
RMDIR := RMDIR /S/Q

# All of the sources participating in the build are defined here
-include sources.mk
-include subdir.mk
-include objects.mk

ifneq ($(MAKECMDGOALS),clean)
ifneq ($(strip $(S62_DEPS)),)
-include $(S62_DEPS)
endif
ifneq ($(strip $(ASM_DEPS)),)
-include $(ASM_DEPS)
endif
ifneq ($(strip $(C55_DEPS)),)
-include $(C55_DEPS)
endif
ifneq ($(strip $(S_UPPER_DEPS)),)
-include $(S_UPPER_DEPS)
endif
ifneq ($(strip $(C++_DEPS)),)
-include $(C++_DEPS)
endif
ifneq ($(strip $(S_DEPS)),)
-include $(S_DEPS)
endif
ifneq ($(strip $(CC_DEPS)),)
-include $(CC_DEPS)
endif
ifneq ($(strip $(C64_DEPS)),)
-include $(C64_DEPS)
endif
ifneq ($(strip $(CPP_DEPS)),)
-include $(CPP_DEPS)
endif
ifneq ($(strip $(S64_DEPS)),)
-include $(S64_DEPS)
endif
ifneq ($(strip $(CXX_DEPS)),)
-include $(CXX_DEPS)
endif
ifneq ($(strip $(C67_DEPS)),)
-include $(C67_DEPS)
endif
ifneq ($(strip $(S67_DEPS)),)
-include $(S67_DEPS)
endif
ifneq ($(strip $(S43_DEPS)),)
-include $(S43_DEPS)
endif
ifneq ($(strip $(C62_DEPS)),)
-include $(C62_DEPS)
endif
ifneq ($(strip $(C43_DEPS)),)
-include $(C43_DEPS)
endif
ifneq ($(strip $(C??_DEPS)),)
-include $(C??_DEPS)
endif
ifneq ($(strip $(ASM_UPPER_DEPS)),)
-include $(ASM_UPPER_DEPS)
endif
ifneq ($(strip $(OPT_DEPS)),)
-include $(OPT_DEPS)
endif
ifneq ($(strip $(S??_DEPS)),)
-include $(S??_DEPS)
endif
ifneq ($(strip $(S55_DEPS)),)
-include $(S55_DEPS)
endif
ifneq ($(strip $(C_DEPS)),)
-include $(C_DEPS)
endif
ifneq ($(strip $(SA_DEPS)),)
-include $(SA_DEPS)
endif
ifneq ($(strip $(C_UPPER_DEPS)),)
-include $(C_UPPER_DEPS)
endif
endif

-include ../makefile.defs

# Add inputs and outputs from these tool invocations to the build variables 

# All Target
all: Conv_Biosv6.out

# Tool invocations
Conv_Biosv6.out: $(GEN_CMDS) $(CMD_SRCS) $(OBJS)
	@echo 'Building target: $@'
	@echo 'Invoking: Linker'
	"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c6000/bin/cl6x" -mv64+ -g -O3 --define=_EVMC6472 --define=_BIOS --diag_warning=225 -z -m"Conv_Biosv6.map" --warn_sections -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c6000/lib" -i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c6000/include" --reread_libs --rom_model -o "Conv_Biosv6.out" $(ORDERED_OBJS)
	@echo 'Finished building target: $@'
	@echo ' '

# Other Targets
clean:
	-$(RM) $(GEN_CMDS__QTD)$(GEN_SRCS__QTD)$(C6000_EXECUTABLE_OUTPUTS__QTD)$(GEN_MISC_FILES__QTD)$(GEN_OPTS__QTD) "Conv_Biosv6.out"
	-$(RM) ".\func_task_1.obj" ".\func_task_2.obj" ".\main.obj" ".\sample_sig_func_1.obj" ".\sample_sig_func_2.obj" ".\tsc_h.obj" 
	-$(RM) ".\tsc_h.pp" 
	-$(RM) ".\func_task_1.pp" ".\func_task_2.pp" ".\main.pp" ".\sample_sig_func_1.pp" ".\sample_sig_func_2.pp" 
	-$(RMDIR)$(GEN_MISC_DIRS__QTD)
	-@echo ' '

.PHONY: all clean dependents
.SECONDARY:

-include ../makefile.targets

                 Regards,

                 Andrey

  • 0
    TI__Genius 9915 points

    I assume you are running the executable from CCS from windows.

     

    Thanks,

    Arun.

  • 0 in reply to ArunMani
    Intellectual 370 points

    Arun,

    I am using CCS only to transfer the Linux-generated executable (.out file) to the EVM board.

  • 0 in reply to Andrey56137
    TI__Genius 9915 points

    Is it possible for you to step through the code. I still doubt that the cahnge you made to compile has to do something with this. Please step through the code once with the working version and once with the faulty once and let me know where exactly, you see the descrepancies.

     

    thanks,

    arun.

  • 0 in reply to ArunMani
    Intellectual 370 points

    OK, so to debug this, I made a DSP/BIOS project and a non-BIOS project with exactly the same code where one core sets a variable in shared memory and another core waits on this variable to be set. Essentially, it looks like this

     


    #pragma DATA_ALIGN(Ready_Flag, 128)
    #pragma DATA_SECTION(Ready_Flag, "SharedMem")
    volatile int Ready_Flag = 0;


    int main() {
         printf( "\nThis core number is %d\n", DNUM );

         if (DNUM == 0) {
             //Set the master flag
             Ready_Flag = 5;
         }

         printf("Core %d, &ReadyFlag = %x, Ready_Flag = %d\n", DNUM,
    &Ready_Flag, Ready_Flag);

         printf("Waiting on ready flag\n");
         while (Ready_Flag != 5)
         {
         }

     

    I am not using Linux at all at this point, both projects were created with CCS.

    So, it appears that in the BIOS project, shared memory works as expected, but not it the non-BIOS one... even though they place the shared variable at the same address. In the BIOS version, I start Core 1, it then stops at the "while" loop, waiting for the flag to be set. Then I start Core 0, it sets the flag, and Core 1 breaks out of the loop. In the non-BIOS version, it stays in the loop forever (apparently).

    I did single-stepping through the code with the memory watch window open in CCS. It appears that the memory view for address 0x00200000 is different between Core 0 and Core 1. In other words, Core 0 says the location has a value of 5, while Core 1 still sees it as 0. This change can be seen by clicking on each core.

    Also, the assembly instructions for both projects appear to be the same for the "while" loop.

    Does anybody know what accounts for this BIOS vs non-BIOS difference? It is especially surprising that the memory view changes from one core to another, considering the address is the same. Maybe I need to manually change some configuration file in the non-BIOS project, or write to a hardware register to enable memory sharing between cores.

    I am attaching the two projects (the source code is very simple).

                            Thanks,

                              Andrey

     

    1220.SharedMem_NonBIOS.rar

     

    4213.SharedMem_BIOS.rar

  • 0 in reply to Andrey56137
    Intellectual 370 points

    OK, one more thing that can help debug this issue: When I view the "error log" in CCS, I see the following message:

    Failed to access memory: address=0x200000 size=4 error code=9

    Unfortunately, I don't know where to look up this error code. It only says that it's coming from com.ti.ccstudio.memory.ui plugin. Could somebody point me to a reference for this error?

  • 0 in reply to Andrey56137
    Intellectual 775 points

    Could you compare ".map" files generated with these two builds (WIndows and Linux)? Are they identical? Is size of ".out" same?

  • 0 in reply to Justin Antony G
    Intellectual 775 points

    For the case when BIOS and non-BIOS projects are used, what is the CACHE configuration (shared memory/L1/L2?)?

    I work on another tri core DSP, where if BIOS is used, it has some default settings for CACHE in the TCF file (BIOS). So if i use non-bios project, the CACHE registers maynot be written the way it happens when using BIOS project.

    Could you check from this angle for you problem?

    Regards,

    Justin

  • 0 in reply to Justin Antony G
    Intellectual 370 points

    Hi,

    The problem was that data cache was enabled by default, apparently. This caused one of the cores to see the cached data, rather than the updated one written by another core. I fixed this by disabling the cache before core synchronization (read/write), and enabling it afterward.