TMS320F28034: Changing the compiler version causes the program to run abnormally

Hello Yutao,

yutao liu said:

First, I want to know if the problem that causes the program exception is caused by a difference in the compiler.

Can you check the disassembly of the two functions and their function calls wherever they're located? You can do this by opening the Disassembly window in the debug session. From there we can try to figure out what is causing this to happen.

Best regards,

Omer Amir

Dear Omer Amir:

  I uploaded a zip package with documentation on disassembly window for both compilers.I hope it gives you some useful information.

Best regards,

Yutao Liu

Difference of the disassembly window.zip

Hello Yutao,

Within the xmodemReceive function, can you use the assembly step options to step through each assembly line in the Disassembly window? That way we can locate what loop it's getting stuck in. Also, if the program runs away after using the normal step option, you can use the pause button to see where the program is stuck.

Best regards,

Omer Amir

Dear Omer Amir:

  When I used the assembly step options to step through each assembly line in the Disassembly window, I found that when the program ran to the code of the memory address (0x3FF8CD), it couldn't go any further and stayed stuck there.

Best regards,

Yutao Liu

Hello Yutao,

Yes, so the program hit an instruction trap (i.e. an invalid instruction is run). You will need to find out what in your code is executed immediately before it jumps to this location in ROM. At or around that instruction, there will be something that is causing the error, such as jumping to a function that has been moved, accessing an array out-of-bounds, etc.

Best regards,

Omer Amir

Dear Omer Amir:

  According to your suggestion, I tried to find the cause of the problem, but I am not familiar with assembly language, which may cause me to fail to find the key to the problem. So I uploaded a video, which contains the data information of every step of my debugging, I hope you can help me look at it and help me find the key to the problem! Thank you very much!

Best regards,

Yutao Liu

Dear Omer Amir:

 Is it possible that the problem is caused by a stack overflow? How can I confirm this?

Best regards,

Yutao Liu

Hello Yutao,

yutao liu said:

Is it possible that the problem is caused by a stack overflow?

No, I don't believe so. This is something to do with the way the code is compiled. You can see in disassembly at 0:20 in the video that there is an instruction FFC which is a Fast Function Call (see the C28x Instruction Set for the full list of assembly instructions) which calls a function in prolog28.asm. This prolog28 function has invalid instructions (delineated as the instruction code 0xFFFF ITRAP). It looks like this may be because the function xmodemReceive is for some reason not accessible (i.e. it's in a locked, secure zone). What sort of memory configuration are you using for your program? Are you running purely from Flash, or are some functions loaded to RAM?

Best regards,

Omer Amir

Dear Omer Amir:

  Is it possible that the function(xmodemReceive) runs in Flash and then calls a function (prolog28.asm) in RAM causing the instruction defect. We can see some differences by comparing the assembly code of the two versions of the compiler.

Best regards,

Yutao Liu

Hello Yutao,

Are you using the same linker command file, project properties, and build configurations that you had from the project that used an older compiler version? I want to double-check because one of the few reasons this type of issue can happen is if memcpy is being used to run a program from RAM after loading it from Flash and the code is not copied correctly, or there is some linker command file change and a function is not loaded to the proper memory unit.

Best regards,

Omer Amir

Dear Omer Amir:

  Everything is the same except that the level of optimization(V15.12.3:level=1 speed=3     V20.2.5:level=1 speed=1) and the compiler are different.

Best regards,

Yutao Liu

Hello Yutao,

How did you change the compiler? Did you just change the setting in the Project Properties or did you create a new project? If you just changed the project properties, I will see if I can forward this query to the compiler team on why this code may have compiled differently.

Best regards,

Omer Amir

Dear Omer Amir:

  Yes, I just change the setting in the Project Properties. 

Best regards,

Yutao Liu

Dear Omer Amir:

  If you need me to provide any materials, please let me know. I would be most grateful if you could help me find the cause of the problem.

Best regards,

Yutao Liu

Dear Omer Amir:

I have found the cause of problem.

Cause: The compiler of V20.2.5 packages some code used during the upgrade into a function(_prolog_c28x_2), which is stored in the flash(0x3f1c86) to be erased before the upgrade, so that the code cannot be called during the upgrade. But I still have a question, which is why the instructions in this function are stored in both flash and RAM?

Best regards,

Yutao Liu

Hello Yutao,

You will need to look at your linker command file to find the location where the code is being stored to; if it's part of some library you can look for that library name. Beyond what's in the linker file, I'm not sure how else the memory location of a function is dictated unless there's a specific #pragma statement.

Best regards,

Omer Amir

The compiler experts state that the locations in memory are being overwritten with ITRAP (invalid instruction) by runaway code or something similar. Please find out when the ITRAP instructions first appear, i.e. are they there after loading, before execution starts, or after executing for a while? You can probably find what is causing this memory to be overwritten that way.

Best regards,

Omer Amir

Hello Yutao,

Now that you have found what's causing the function to be erased, you should be able to adjust your memory allocation to prevent this. I will close this thread unless you have further questions.

Best regards,

Omer Amir

Dear Omer Amir:

  Thank you for your patient answer these days, which is of great help to me and enables me to learn a new way to troubleshoot problems.

Best regards,

Yutao Liu

Of course, always happy to help out.