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.
Part Number: TMS320F280048
Hello,
I have been running my code from flash and am looking to speed up the execution time by running it out of RAM. I read through and followed the instructions mentioned in this app note: http://www.ti.com/lit/an/spraau8a/spraau8a.pdf
I modified my linker command file and the codestartbranch.asm files and modified and used the DSP28xxx_SectionCopy_nonBIOS.asm file from the app note for copying the compiler sections from Flash to RAM at startup. The code compiles and am able to flash but after flashing it the code gets stuck at address 0x3fbd92 with the following message:
Break at address "0x3fbd92" with no debug information available, or outside of program code.
Below is a screenshot of the debug window. I am not sure what or where the issue might be.
Also I have attached the linker command file, the modified codestartbranch.asm and DSP28xxx_SectionCopy_nonBIOS.asm files.
Sandeep,
Please see the following related thread:
https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/812692
I hope this helps. If this answers your question, please click the green "Verified Answer" button. Thanks.
- Ken
Sandeep,
It looks like you would like to boot from flash and copy sections of code to RAM. The following application report might be useful to you:
Even though the application report uses a different MCU, the concepts will be the same.
Also, reviewing the F28004x workshop might be helpful, too. Please note that the materials (links) will be active in the next few days:
https://training.ti.com/c2000-f28004x-microcontroller-workshop?cu=1137791
I hope this helps. If this answers your question, please click the green "Verified Answer" button. Thanks.
- Ken
Ken,
From what I understand, spra958 describes the procedure for copying specific functions/sections into RAM. However I would like to copy the whole code/compiler sections into RAM before the start of execution for which I followed spraau8a. I am using the control card and have the boot mode select set to boot from Flash.
After some modifications to the Linker command file, codestartbranch.asm files and DSP28xxx_SectionCopy_nonBIOS.asm yesterday, the code that I have now is stuck at the beginning of RAM (0x000000) and does not point to the start of main() after booting.
Sandeep,
Here are some debug tips that can help:
1) In your latest snap, control is at code_start. You may have disabled "run to symbol main" on "a program load or restart" in the debugger settings (Check CCS Debug view -> Tools -> Debugger options -> AutoRun and Launch options").
If you step from the code_start, what does it do? Ideally, if you map things correctly, control should go to watch disable code from here before it starts copying sections to RAM.
2) At code_start, there is a long branch to 0xC76B. Did you check what is loaded at that address? In your linker cmd file, that address is in PAGE 1. Is it intentional? I am not sure what you mapped there. Please check.
3) In your codestartbranch asm file, you coded ".text wd_disable". Do you mean to code ".sect "wddisable""? I see you mapped wddisable to Flash in your linker cmd and hence asking.
4) There is 256KB of Flash and 100KB of RAM on this device. Hence, if you want to map all the sections to RAM, you need to make sure your application won't exceed 100KB - Did you already analyze this?
5) Make sure to remove memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize) since the code gets copied by "DSP28xxx_SectionCopy_nonBIOS.asm" even before reaching _c_int00.
6) Did you replace any .sect “ramfuncs” (or .sect ".TI.ramfunc") in any of the asm files to .sect “text” so that "DSP28xxx_SectionCopy_nonBIOS.asm" can copy those sections as part of .text section? I see that sectioncopy asm does not copy ramfuncs and hence asking.
7) Also in your application, please remove any #pragma CODE_SECTION(xx, “ramfuncs”) (or #pragma CODE_SECTION(xx, “.TI.ramfunc”)) so that they get mapped to .text section.
8) Looks like you started the thread showing an ITRAP error. Are you able to get rid of the ITRAP now?
Hope this helps.
Thanks and regards,
Vamsi
Sandeep,
Also note that you can take advantage of the Flash prefetch mechanism and data cache available in Flash wrapper to improve Flash performance. You may have already noticed this - just in case.
Hope you configured Flash wait-states to 4 for 100MHz operating frequency.
Thanks and regards,
Vamsi
Hi Vamsi,
Thanks for looking into the issue. I apologize for the late reply!! I had some other tasks to attend to.
I did manage to check the Flash settings. The wait state is set to 4 and Flash prefetch and data cache are Enabled.
As for other suggestions you had below are my comments:
1) In your latest snap, control is at code_start. You may have disabled "run to symbol main" on "a program load or restart" in the debugger settings (Check CCS Debug view -> Tools -> Debugger options -> AutoRun and Launch options").
If you step from the code_start, what does it do? Ideally, if you map things correctly, control should go to watch disable code from here before it starts copying sections to RAM.
- I checked the debugger options and "run to symbol main" on "a program load or restart" is checked/Enabled.
When I pause the execution for single step looks like it is stuck at "00c5ea" which seems to be part of RAMGS0 and I do not have any instructions to copy any sections into this portion of the RAM in my linker file. So I am not sure how the program gets to this address.
2) At code_start, there is a long branch to 0xC76B. Did you check what is loaded at that address? In your linker cmd file, that address is in PAGE 1. Is it intentional? I am not sure what you mapped there. Please check.
- This is not intentional. This seems to be a part of RAMGS0 and I do not have any sections assigned to this portion of RAM. So I am not sure why the branch instruction to this address is there.
3) In your codestartbranch asm file, you coded ".text wd_disable". Do you mean to code ".sect "wddisable""? I see you mapped wddisable to Flash in your linker cmd and hence asking.
- I had already modified the files that I attached at the beginning before my last post to change .text to .sect, but forgot to attach the files in my last post. Please check the attachment below for the updated files.
4) There is 256KB of Flash and 100KB of RAM on this device. Hence, if you want to map all the sections to RAM, you need to make sure your application won't exceed 100KB - Did you already analyze this?
- The application does not exceed the RAM limit. Before I started making changes to copy the code from Flash to RAM, I changed my Active Build Configuration to CPU1_RAM and was able to run the application from RAM with the debugger connected. I did not have any issues when I did this and noticed the faster execution time.
5) Make sure to remove memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize) since the code gets copied by "DSP28xxx_SectionCopy_nonBIOS.asm" even before reaching _c_int00.
- I commented out this memcpy section inside the InitSysCtrl() funtion as per your suggestion, but this did not change the outcome.
6) Did you replace any .sect “ramfuncs” (or .sect ".TI.ramfunc") in any of the asm files to .sect “text” so that "DSP28xxx_SectionCopy_nonBIOS.asm" can copy those sections as part of .text section? I see that sectioncopy asm does not copy ramfuncs and hence asking.
- The asm files did not have any .sect “ramfuncs” (or .sect ".TI.ramfunc"). I added instruction to the "DSP28xxx_SectionCopy_nonBIOS.asm" to copy the ramfuncs sections after my last post. Please check the attached files below to review the instructions used for copying this section.I do not know if this is required or not. This however did not make any difference.
7) Also in your application, please remove any #pragma CODE_SECTION(xx, “ramfuncs”) (or #pragma CODE_SECTION(xx, “.TI.ramfunc”)) so that they get mapped to .text section.
- I do not have these instructions in my code.
8) Looks like you started the thread showing an ITRAP error. Are you able to get rid of the ITRAP now?
- After the changes I made to the .asm and the liker command file before my last post I do not get the ITRAP error now.
Please let me know if you need any more info!!
Sandeep,
Please check the map file to see what is mapped there. That will give you clues for further debug.
Note: I will be on vacation until July last week. I will assign this post to another team member if you need further help.
Thanks and regards,
Vamsi
Hi Sandeep,
I haven’t heard from you for 10 days, so I’m assuming you were able to resolve your issue. If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information. If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.
Regards,
Katta
Hi Sandeep,
Could you able to resolve your issue? Please let me know if you have any update.
I have looked into your modified linker command file.
Can you step in the code and check if the Flash content for .text, .cinit, .pinit, etc. are copied to RAM?
I don't think you can copy all the section if it exceeds more than a single LSRAM with below command
RUN = RAMLS0 | RAMLS1| RAMLS2 | RAMLS3 | RAMLS4_5 | RAMLS6 | RAMLS7,
You need to use combined RAM such as
RUN = RAMLS4_5
Thanks,
Katta
Hi Katta,
Thanks for the reply. I still have the same issue. I have been working on some other topics and haven't been able to spend much time on this.
I did check the .map file like Vamsi suggested and did not see anything specifically mapped to the location 0x00c5ea. I will attach the .map file for your review.
As for your suggestion how would I check if Flash content for .text, .cinit, .pinit, etc. are copied to RAM by stepping in the code?
For the issue "I don't think you can copy all the section if it exceeds more than a single LSRAM with below command"
RUN = RAMLS0 | RAMLS1| RAMLS2 | RAMLS3 | RAMLS4_5 | RAMLS6 | RAMLS7,
I did get an error during compilation that you mentioned above when I used RUN = ..... command for the .text section.
But when I changed the command to: RUN >> RAMLS0 | RAMLS1| RAMLS2 | RAMLS3 | RAMLS4_5 | RAMLS6 | RAMLS7, PAGE = 0 for .text, .switch and .econst sections. the error went away. I think this command splits the section copy into the specified RAM sections.
I have also attached a screenshot of the memory allocation.
Please let me know if you want me to try/check anything else.
Thanks!!
Hi Sandeep,
You will not get a compilation error. The command won't split the sections as it does in other cases. This is a different case where the sections are copied run time. This query can be separately discussed in compiler forum.
To observe if the copy happened as expected from FLASH to RAM. You can step in to the code post to the location where the copy occurred. Watch the
XXXX_loadend, XXXX_loadsize, XXXX_loadstart values. where XXXX is cinit, text, econst etc.
I have one more observation.
If you observe in the map file the loadsize parameters have valid values when there is a single section. The length of the section matches _loadsize parameter.
.cinit 0 00084129 0000008a RUN ADDR = 0000b157 -------------> Line no. 163
0 000841b3 _cinit_loadend
abs 0000008a _cinit_loadsize -------------> Line no. 1470
0 00084129 _cinit_loadstart
0 0000b1e1 _cinit_runend
abs 0000008a _cinit_runsize
0 0000b157 _cinit_runstart
.TI.ramfunc
* 0 000841b3 0000018e RUN ADDR = 000000f5 -------------> Line no. 236
0 00084341 _RamfuncsLoadEnd
abs 0000018e _RamfuncsLoadSize -------------> Line no. 1365
0 000841b3 _RamfuncsLoadStart
0 00000283 _RamfuncsRunEnd
abs 0000018e _RamfuncsRunSize
0 000000f5 _RamfuncsRunStart
But in other cases the loadsize value is 0xffffffff which is invalid.
As i have suggested please use a combined ram instead of ORing the RAM sections.
Please let me know after you try with the changes.
Thanks, Katta
Hi Katta,
I tried out your suggestion of combining the RAM into a single block. I still have the same issue as before.
I also stepped to the RAM addresses to check if the code was copied but it looks like it was not. What could be the reason for this?
I have attached the files for your review.
Thanks!!
Unfortunately, I do not understand everything happening in this situation. But I think I can shed some light on it.
There is more than one way to allocate code to flash, then copy it over to RAM for execution. In this case, it seems there are two methods being used at once. One is the application note Copying Compiler Sections From Flash to RAM on the TMS320F28xxx DSCs. The other method is the ramfuncs feature of the compiler tools. Please do NOT combine these methods. Pick one or the other, then use it exclusively.
For any method you use, you have to understand exactly what happens when execution begins. That first routine must be present in memory and immediately ready for execution. The code that executes the copy from flash to RAM must itself be present in memory and ready for execution. This code cannot itself be allocated to flash for load and RAM for run. It can only be allocated to one location for both load and run.
For general help with changing the linker command file, please see the article Linker Command File Primer.
Thanks and regards,
-George