TDA2HG: EVE Kernel output mismatch in Debug & Release Mode

Hi Rohan,

      Can  you look at the difference in the assembly code of the kernel (_vloop function) in release and debug mode. See if there is any instruction which has dependency on previous instructions and its getting executed along with that instruction.

Regards,

Anshu

Hi Anshu,

I have compared the autogenerated .c files of the kernels and do not see any difference in terms of code in debug and release mode.

I am not aware how assembly files of kernels are generated. Can you please tell me how they are generated? As I read in one post that the option --keep_asm will generate assembly file but this did not work for me.

It would be of great help if you can tell me the complete instruction for generating the assembly files for the kernel and also the applet.

Regards,

Rohan

Hi Rohan,

   You just need to add ----keep_asm flag to the compile options to generate the asm files.

Regards,

Anshu

Can you test:

Kernel + Applet tested on platform with build in debug mode .

You don't need to integrate into vision SDK for that. Just load and run your *.out file on ARP32 through Code Composer.

regards,

Victor

Hi Victor,

Thanks for the response.

I have already tested Kernel + Applet tested on CCS simulator by loading the out file with build in debug mode. The output is accurate.

When I build this Kernel +Applet in Release mode there is a mismatch in the output. Hence I want to know is there any method by which I can know the behavioral difference in release mode as it is not possible to set breakpoints in release mode.

Please let me know a method.

Regards,

Aniruddha Nadgouda

Hi Aniruddha,

I would like you to test the debug version of your *.out file on CCS by loading it onto the EVM, not by using the simulator. Sometimes issues happen on the EVM only.

regards,

Victor

Hi Victor,

I understood the point. I tried to load the .out file  and test but could not do so.

The procedure I followed is as follows:

1. Launch the configuration with gel files.

2. After that I first connected A15 core.

3. Then I selected the following options of CCS :

Scripts->TDA2XX MULTICORE Initialization -> TDA2XX_MULTICORE_EnableAllCores

4. Connect EVE1 and then load the program. Here I loaded the .out file

On doing so EVE goes into running mode and does not get suspended at the start of the application.

Please let me know is this the right procedure else how to perform this task

Regards,

Aniruddha Nadgouda 

HI Aniruddha,

    Before loading the binary to EVE can you do CPU reset from CCS?

Regards,

Anshu

Hi Anshu,

Yes I can do CPU reset after connecting EVE before loading the binary. Still after loading the binary, EVE goes into running state and does not suspend at the start of the application.

Just for your information I have kept the switch settings of the board in Debug and tried this.

Regards,

Aniruddha Nadgouda

Hi Aniruddha,

  Have you followed all the steps in section 3.6 of eve_sw_getting_started.pdf? Specifically point 1?

Regards,

Anshu

Hi Anshu,

Thanks for the input. I had missed the first step of modification in the Gel file.

Going back to the original problem I could load the binary and test the .out file in the debug mode. While testing I realized 1 big difference that the VCOP ( IBUFs,WMEM) memories get initialized to 0 in the simulator in the simulator where as in the hardware this is not the case. It is not initialized to 0.

Please confirm this.

My kernel is not by a traditional method where every element of output memory is generated from processing hence there was a garbage being transfered from IBUFH to DDR in output DMA transfer.

I have used a work around for this problem by using memset for output memory and transferring it. This acts as a memset for every block.

Still I am getting a different in the computation part as well in the hardware and so output is not matching in the hardware debug build which is matching perfectly in the simulator debug build. Is operation level difference also expected to happen on hardware?

Also I have observed a difference that when we input DMA call for input is triggered the input gets reflected into IBUFL. Whereas when I step ahead the input in the memory browser becomes 0 automatically. I do not find this normal and makes it hard to debug. Can you suggest how I can go ahead with this?

Hi,

Yes the simulator automatically sets all the memory output to 0 but in the hardware, the memory state is undefined, with random values present at power-up.

When you build in debug, all variables, global arrays are initialized to 0. But in release, this is not the case. So make sure that you initialize all the variables/array that you use. Don't assume that they are initialized to 0 at runtime.

Regarding your last question, you are seeing memory getting filled to 0 probably after a function call VCOP_BUF_SWITCH() which switches the IBUFL ownership from the system (DMA, ARP32, CCS Memory browser) to VCOP. This is normal behaviour as VCOP needs to access the buffer in order to operate on it. But then you loose visibility to it.

It is possible to manually switch back to the system by setting the register MEMSWITCH_CTL @0x40080000, but only after your VCOP function has operated on it. Please refer to the eve's programmer's guide for more details.

The simulator allows you to view the content of the IBUFL irrespective of the value of MEMSWITCH_CTL, so it is easier to debug your code, indeed.

regards,

Victor