CCS/TMS320F28377D: 0x3FE493(no symbols are defined) error after clicking debug button; Failed to auto-run to main()

Hi John,

Please refer https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/396203

Please include F2837xD_CodeStartBranch.asm and set the entry point to code_start.

Also please try to use a reference example in c2000ware and check if you notice a similar behavior.

Thanks,

Katta

Hi Katta,

F2837xD_CodeStartBranch.asm is already in my CCS project and code_start has been set to be my entry point all the time. You can see it in my map file code_start is at 0x80000 which is the FLASHA. And I chose to use boot to flash setting.

Additionally, I can safely go into _c_int00 as stated above. It was when hardware breakpoint was set at Line 224 of boot28.asm that the problem occurred. And _c_int00 is in boot28.asm file. Besides, the function of code_start is to take the application to _c_int00. So I think that is not the cause.

Regards,

John

Hi John,

Can you use FLASH-B,C,D,E, for allocating .text?

Is there are reason behind using "F2837xD_FPU_RFFT_lnk.cmd" or do you need a generic linker command file?

Please let me know your use case so that we can see if we have a reference examples closer to your use case.

Thanks,

Katta

Hi Katta,

Thank you for your reply. My .cmd file was modified based on F2837xD_FPU_RFFT_lnk.cmd. But I didn't change the name in the notation since it's not a formal project. I was just trying out different setting for memory allocation. Sorry for the confusion.

Back to the topic, I have tried another approach since our last correspondence. Here is what I did.

1. Create a new CCS project.

2. Put functions in main() to set a GPIO pin to be output and toggle it.

3. In .cmd file, specifically allocate rts2800_fpu.lib<startup.c.obj> (.text) at the end of FLASHN.

4. Build the project without any error messages and press the debug button.

After I have gone through the steps above, the same problem still occurred. So I think it's safe to say that the default _system_post_cinit() function cannot be put at the end of the FLASHN. If you know the root cause of this, please tell me. Thank you.

Here is part of my .cmd file used in the flawed case.

FLASHN : origin = 0x0BE000, length = 0x001FFF /* on-chip Flash */
FLASHEND : origin = 0x0BFFFF, length = 0x1 /* Reserved space for flash */

customizedtext : {--library=rts2800_fpu32.lib<startup.c.obj> (.text)} > FLASHEND, PAGE = 0
.text : >> FLASHE, PAGE = 0

Regards,

John

Hi John,

May I know what are you trying to do with step #3.

In the default linker command file can you just try to modify the .text allocation as it won't fit your code space?

Do not add anything related to rts2800 lib allocation and let me know if you see any issue.

Meanwhile let us know your use case so that we can see if we have a reference examples closer to your use case.

Is there are reason behind using "F2837xD_FPU_RFFT_lnk.cmd" as the base for your linker command file or do you need a generic linker command file?

Thanks,

Katta

Hi Katta,

Thank you for your reply.

Reason for step #3: I was trying to find the reason why the issue appeared. Since the problem occurred when hardware breakpoint was inserted in _c_int00, specifically line224 which is near _system_post_cinit() function as you can see in the figures provided in original post, I assume there is something wrong with rts2800_fpu.lib<startup.c.obj> (.text) allocation. _system_post_cinit() function is in startup.c source file which can be found in compiler folder.

The reason for this has been mentioned in my previous post. For example, if I changed the allocation of rts2800_fpu.lib<startup.c.obj> (.text) to FLASHA or FLASHG instead of being at the end of FLASHN, and kept everything else exactly the same, the problem disappeared. By the way, at first rts2800_fpu.lib<startup.c.obj> (.text) section was allocated by the linker at the end of FLASHN automatically. I simply defined a range in which .text section should reside, and I did not do anything to change specific .text section allocation for any .obj file.   The entire .text allocation was done by the linker.

Can .text fit into my code space?: Yes, it can fit into my code space. Of course I could simply move the code to other Flash sectors and problem solved. But since it's my second time encountering this issue, I would like to find out the reason behind it, especially when I think I did nothing wrong in terms of memory allocation.

The problem was encountered when I was trying to reallocate my code from running out of RAM to FLASH. At first, I let the linker do the auto-allocation for the whole .text section within the range of FLASHK to FLASHN backwards. After I built the project and pressed the debug button the error message occurred. In other words, at the beginning, I did not change anything about the rts2800.lib section allocation. It was just the linker automatically allocated the 1-byte rts2800_fpu.lib<startup.c.obj> (.text) section to the end of FLASHN.

As for the reason using F2837xD_FPU_RFFT_lnk.cmd as base, I was doing a signal processing project which requires me to use CFFT using 64-bit floating-point calculation which is not supported in hardware and provided in the controlSUITE examples. Therefore I decided to use a .cmd file relative to CFFT_f64.c(wrote it myself) and modified it from there since most of the memory allocation for both cases might be similar.

Regards,

John

Hi,

Please try below 2 points and let me know what happens:

1. Remove the hardware break point. Symbols not defined is not an error. It means there is no code associated at that point.
2. Give the size = 2 instead of 1  in linker command file.

Is it possible to share your project? Please remove any of your copyright content I will see if i can run on my board.

Thanks,

Katta

Hi Katta,

The hardware breakpoint was not there the first time I tried to debug the project and the problem still occurred.

I have tried the following.

1. Remove the hardware breakpoint and let the linker allocate the whole .text section automatically.------Problem occurred.

2. Reallocate 1-byte rts2800_fpu.lib<startup.c.obj> (.text) section to the 2-byte space at the end of FLASHN.------Problem occurred.

Part of contents in .cmd file is like this:

FLASHN : origin = 0x0BE000, length = 0x001FFE /* on-chip Flash */
FLASHEND : origin = 0x0BFFFE, length = 0x2 /* Reserved space for flash */

customizedtext   : {--library=rts2800_fpu32.lib<startup.c.obj> (.text)} > FLASHEND, PAGE = 0

.text            : > FLASHN,    PAGE = 0

3. Reallocate 1-byte rts2800_fpu.lib<startup.c.obj> (.text) section to the 3-byte space at the end of FLASHN.------Problem solved.

I built a new project with a simple GPIO function in main(). And I did the experiments under the condition of step#2 above. The result was the same. That is that when I specifically allocated 1-byte rts2800_fpu.lib<startup.c.obj> (.text) section to the last 2-byte space of FLASHN, the problem occurred. Additionally, even if it was put in the last 1-byte space of FLASHN, the same problem occurred still.

Here is the new project that I built in which the 1-byte rts2800_fpu.lib<startup.c.obj> (.text) section was allocated at the last 2-byte space of FLASHN. If you don't mind, you can try it on you board to see if you get the same issue. Thank you.

DSP Test.zip

Regards,

John

Hi John,

Try with one of the below changes:

1. Remove the customizedtext  part. If you compare the modified memory map file, "rts2800_fpu32.lib : startup.c.obj (.text)" is allocated. You need not allocate is specifically.
2. If you wish to use the customizetext use the "FLASHEND : origin = 0x0BFFF8, length = 0x2" and make the changes for FLASHN as size 0x001FF8

With either one of the above changes, I could see the program reached main when i tried to debug.

Thanks,

Katta

Hi Katta,

Thank you for the work and your reply.

1. I know I do not need to allocate rts2800_fpu32.lib : startup.c.obj (.text) section specifically. And at the beginning I did not do that. But if I let the linker do its allocation for the entire .text output section, like I originally did, there is a chance that it will be allocated to the end of FLASHN and cause the issue we are discussing here. By reducing the space of FLASHN, excluding the last few bytes of FLASHN memory in .cmd file, it will prevent the linker from automatically allocating this section to the end of FLASHN, but I would like to know the real cause of this.

2. As long as rts2800_fpu32.lib : startup.c.obj (.text) section is not put at the end of FLASHN, debug process seems alright. However, I would like to find out the reason behind it. Otherwise maybe something like this happen again and maybe the allocation of rts2800_fpu32.lib : startup.c.obj (.text) section is not the root cause here, then I will not know how to debug it then.

If you know the root cause of this issue, please let me know. Is this a bug of Code Composer Studio, or a hardware issue of this DSP device, for example the end of the FLASHN cannot contain instructions such as LRETR?

Regards,

John

Hi John,

I am not sure how you have faced the issue in the first place as it didn't occur when i commented the line  rts2800_fpu32.lib : startup.c.obj (.text).

I will check with compiler team about this.

Thanks,

Katta

Hi Katta,

Thank you very much for your help.

There are a few things I would like to clarify.

1. The project I provided is just a test project that I built specifically to verify my theory that the rts2800_fpu32.lib : startup.c.obj (.text) being allocated to the end of FLASHN is the cause of this issue.

2. In the original project that I am working on, the .text output section is much larger than that of the test project I provided. And in the original project, I did not manipulate the rts2800_fpu32.lib : startup.c.obj (.text) allocation. It just happened to be allocated at the end of FLASHN by the linker itself while the entire FLASHN and other flash sectors being occupied by other *.obj(.text) sections. That was the condition where I encountered this issue at first.

Part of cmd file when I first encountered this issue:

   .text     : >> FLASHN  |  FLASHM  |  FLASHL  |  FLASHK,    PAGE = 0

Sorry for the confusion caused.

Regards,

John

John,

I did not go through the entire thread.

I read through your last reply and wanted to mention one thing.

You should not use the last 256-bits of the Flash (sixteen 16-bit words should be reserved) when the Flash prefetch mechanism is used.  If used, Flash wrapper will try to prefetch the code from unimplemented Flash space.

Note that Flash initialization routine (provided in C2000Ware) enables this prefetch mechanism. 

Please check if you are using the last 256-bits of the Flash.

Thanks and regards,
Vamsi

Hi Vamsi,

Sorry for the late reply.

I have checked my flash usage. The last 256 bits are indeed occupied by part of .text section.

But I don't think that's the cause of the issue.

Vamsi Gudivada said:

Note that Flash initialization routine (provided in C2000Ware) enables this prefetch mechanism. 

Are you referring to InitFlash() function which must run in RAM rather than in Flash?

It is my understanding that the Flash initialization routine is the function which is called InitFlash() in InitSysCtrl() provided by TI.

Thus, the reasons that I don't think this is the cause are the following:

1. The issue occurred before the debugger can take the application to main(). In other words, the InitFlash() flash initialization routine has not yet run its course and enabled the prefetch mechanism.

2. I have checked the FRD_INTF_CTRL register after the issue occurred. The prefetch mechanism has been disabled.

3. As I have mentioned in my previous posts, the problem occurred when rts2800_fpu32.lib : startup.c.obj (.text) section was allocated at the end of FLASHN, or at the second to the last byte of FLASHN. However, the issue disappeared if I manually move the rts2800_fpu32.lib : startup.c.obj (.text) section to the third to the last byte of FLASHN. If prefetch mechanism is the one that's been causing the problem, then it couldn't be solved as long as there is code in the last 256 bits of Flash memory. And yet as long as I re-allocated the 1-byte rts2800_fpu32.lib : startup.c.obj (.text) section to other places(for example FLASHA or FLASHG or FLASHJ) rather than in the last byte or the second to the last byte of FLASHN while keeping other .text sections in the rest of FLASHN(some .text sections were occupying last 256 bits of Flash memory), the problem was solved.

If you don't mind, you can use the test project that I provided in my previous post to see that the 1-byte rts2800_fpu32.lib : startup.c.obj (.text) section allocation is the probable cause. Once I moved this section away from either the last byte or the second to the last byte of FLASHN, the issue disappeared.

Best regards,

John

John,

I went through the entire thread. I understand what you explained.

1. Regarding Flash initialization: If not your application before reaching main(), I wonder something else (can be Flash tools Or a previous run of your application Or something else) is enabling the prefetch.  Can you modify your CCS debugger settings to not run the code to main() upon load and see whether the prefetch is enabled or not before executing even the codestartbranch code?

2. Regarding the prefetch disable check that you did: When you encounter the issue, I think there is a reset happening in this case. Reset causes the prefetch bit-field to get set to default value. This is what you are seeing.  Can you check if there is a toggle on XRSn when you encounter this issue?

3. Regarding the last 256 bits: I understand a few differences in where you place your code in the last 256-bits is making a difference. Please note that there are many different corner cases that can cause this (failure may not happen in all the cases). Failure happens based on different things: Waitstates, instruction length, instance at which the branch happened to that instruction, type of instruction etc. It is not needed to dive in to this. Irrespective of whether prefetch is enabled before or after the main(), the last 256-bits of the Flash should not be used and should be reserved in the linker cmd.  I filed a ticket internally to reserve these bits in the TI-supplied linker command files.  

Things that we need to consider in this type of debug:

1) Watchdog: You already confirmed that the code_start is the entry point. This means that watchdog gets disabled as part of codestartbranch.asm before reaching cinit sequence.

2) ECC errors: You might end up in this scenario if ECC is not programmed correctly for the code that is placed at FLASHN at the end. However, you are using TI flash tools (CCS Flash Plugin) with AutoEccGeneration option enabled (it is enabled by default in CCS Flash Plugin).  Hence, ECC errors should not happen. Can you confirm that you did not modify any default CCS On-Chip Flash Plugin settings?  

Another reason for ECC errors could be that the prefetch mechanism is fetching the code out of Flash bank space (as you locate code at the Flash bank end) and this will result in Flash ECC errors.  Do you have an ISR for Flash uncorrectable errors?  If you have this, the application will end up in this ISR when Flash ECC error occurs (you can include an ESTOP for your debug in the ISR). 

Did you try to look at the RESC Register and NMIFLG Register to know if there is a reset happening (and the source of the reset)? Please check TRM if you need more details on this.

Thanks and regards,
Vamsi

John,

As per TRM's BootROM chapter, address "0x3FE493" relates to ITRAP ISR.

Please check: http://processors.wiki.ti.com/index.php/Interrupt_FAQ_for_C2000#Q:_What_causes_an_illegal_.28ITRAP.29_interrupt.3F

Thanks and regards,
Vamsi

Hi Vamsi,

Thank you for your time for going through the previous posts.

I did the following.

1. After loading the application to flash and the issue occurred, "reset" button in CCS was pressed. In this state, prefetch mechanism was not enabled as shown in the figure below.

Then a hardware breakpoint was inserted at "LB wd_disable" instruction, the first instruction in code_start to disable watchdog. Press "resume" to let the application run to the breakpoint. Check Flash prefetch mechanism enable bit now. The result is as the following.

So in either case, Flash prefetch mechanism is not enabled.

2. Regarding the reset, XRSn bit and WDRSn bit in RESC register were not set. In a working project, watchdog will be disabled no matter whether I disable it or not at the start of code_start as long as the device is connected with the debugger and is being debugged(I have confirmed this with another TI engineer in another thread and checked the WDCR register after loading the program and stopping at main to see that is the case. According to him, GEL files will do something to disable the watchdog automatically while debugging with the debugger connected and will block watchdog reset even if there is one, which I have also confirmed correct during the debug of that problem).

3. I understand that if prefetch mechanism is enabled, the last 256 bits might not be safe to use. Do you mean even if the prefetch mechanism is not enabled, the last 256 bits of Flash memory still cannot be used?

4. I have checked the FlashEccRegs. ECC is not enabled after I pressed "debug" button and when the issue occurred.

After "reset" in CCS and "resume", ECC was enabled, but the problem persisted.

"Auto ECC generation" option in flash settings has been enabled. I didn't modify anything.

5. NMIFLG register looks fine to me as well.

Best regards,

John

John,

Thanks for checking those things.

I used your project DSP Test and tried to load and execute DSP Test.out.

I did not face any issue.  I am not able to reproduce the issue using your project/.out file.  I did not even recompile.

Not sure why you are seeing this issue.

Couple of questions:

1) What CCS version are you using? I tried it on CCSV9.1.0.  It has the latest Flash programming tool and device xml/gel etc. Not sure if this is making any difference. Can you try this CCS version?

2) Did you program any security setting? When you open Sector N in your debugger memory window, do you see the expected values?

Thanks and regards,
Vamsi

Hi Vamsi,

Thank you for your reply.

I tried to build and load the DSP Test project again on two of my boards, and the same issue occurred on both cases. The CCS version that I'm using is 9.1.0.00010, and the compiler version is TI 18.12.2.LTS. The silicon revision is "C". And the BOOTCTRL registers are not modified(default boot mode select pins GPIO72 and GPIO84 are pulled high). Default boot to flash. I did not touch any security settings of the device.

Katta tried the test project and got the same issue as mine.

I think I understand your point. Anyway I will use the workaround method and reserve the last 256 bits for now. Thank you for your help.

Best regards,

John

Hi Vamsi,

I have loaded the boot symbols and checked the iTrap_addr. It's not part of Flash. In fact it's far from the end of Flash.

Regards,

John

Hi Vamsi,

Although I'm still thinking why it went to that address(it's far from the end of Flash), I'll let it pass for now. Thank you for your help.

Best regards,

John