ADSP-21371 program memory corruption

Further investigations. I started from begin by debugging the SPI kernel while it is fetching the LDR from flash. By adding some check on section headers I found where the issue begin. The address 0x0020AAA6 (48bit address space) is the second-last of its section which header is (TAG=0x00000004 - COUNT=0x0000FFFC - ADDRESS=0x00300000 (32bit address space)): the first address of next section should be: 0x00300000 + 0x0000FFFC = 30FFFC (32bit) = 20AAA8 (48bit).

But when the kernel loads the header of the following section this is what it founds (TAG=0x00000004 - COUNT=0x0000FFFC - ADDRESS=0x0030FFFA) which overlaps with the previus section, and is also not 48bit aligned because not multiple of 3! And this corresponds exactly with the content of the LDF file generated by visual dsp.

The problem is inside the LDR file!

Now it could be an issue of my custom LDF which is quite simple and worked ok for the last 6 years. Also I do not understand how this is related with the added "CASE 215:" in the switch statement...

Has anyone ever had this kind of problem?

Hello,

Can you please share your code to assist you better on this?

Best Regards,

Jithul

Hello!

As I said slight changes of any part of the source code would make the issue to disappear. I cannot give the entire project as it is property of my company and for me is impossible to create a test project to share, because as I delete part of the source codes the problem vanishes. I can share the DXE and LDR if you need, just to show the issue in the generation of the LDR section header.

Link to DXE

Link to LDR

Link to SPI Kernel

Visual DSP generates the LDR with this options:

elfloader.exe -proc ADSP-21371 -bSPI -fHEX -HostWidth 8 -NoBitReverse -l Kernel_21371_spi.dxe -t65530 -o .\Release\F16.ldr -NoInitialWord -v .\Release\F16.dxe -MM

The first section affected starts at line # 13723 of the LDR file:

:20A9EC0004000000FCFF0000FAFF3000010000003E07010000003E07120700003E07DE0B50

from where I extracted the header TAG=0x00000004 - COUNT=0x0000FFFC - ADDRESS=0x0030FFFA which starts a program memory sdram section which results to be not 48bit-aligned

Hello,

Sorry for the delayed response. From the information given above, I do not see anything obvious that has gone wrong.

I have couple of suggestion to debug the issue further.

1) Did you enable compiler optimization? If yes, can you please refer to below FAQ?

FAQ: Why does my code stop working when I enable optimization?

2) Do you have any of your code or data resides in SDRAM, in that case can you please confirm that the SDRAM configuration is done properly in the kernel file?

3) One way to debug your application which is not booting properly is to edit your boot-kernel.asm such that the first executed instruction is JUMP(PC,0);. This way, the part will load the boot-kernel and then just sit there executing the same instruction over and over again. After you reset the board and it starts booting, you connect the DSP with the emulator (be sure the session is configured to NOT reset upon connection), change that instruction to a NOP; in the disassembly window, and then step/run through the rest of the boot sequence. By this way you can exactly find the flow of your code.

Best Regards,

Jithul

Hello, to answer your questions:

1) No, the compiler optimizationa are not enabled

2) The firmware resides mostly on SDRAM but I'm sure the configuration is correct because the same code is shared by the kernel, the firmware and also the same values used to initialize the registers are also used in the XML customization file for the Visual DSP session. I remark that the program works ok if loaded by emulator, both in debug and release configuration.

3) That it exactly what I did to find out that the problem resides in the LDR file. By breaking the flash loading process in the kernel execution I found that from a certain address the LDR instructs the kernel to load a program memory section to a misaligned address and that breaks everything as the C main function is part of that section.

In the following image you can see how the program memory content (and the corresponding assembly) changes from the 20AAA8 address. On the left the correct values loaded from emulator, on the right the content loaded by the kernel from the LDR. It is not immediate but the corrupted memory is equal to the correct one, but misaligned of 2x32bit word (4/3 of a 48bit word) and a little scrambled by the endianness correction.

At the moment I solved by making some changes on the source code, for example by changing the case number in the switch case statement. But I'm really struggling to discover the cause of this issue!