Function(s) Not Loaded in RAM

janet said:

Ok, thanks. Are you still using TI-RTOS 2.12.1.33?

Yes.

janet said:

Are these functions loaded in Flash and are supposed to be copied to RAM?

No, they are loaded in RAM.

Joseph,.

Can you attach your .map file? What gel file are you using? Can you build and run one of the kernel examples?

Todd

ToddMullanix said:

Can you attach your .map file?

Please see attached.  Note that in this instance, the first function not loaded in RAM that I notice is gpio_init().

ToddMullanix said:

What gel file are you using?

I'm not sure if I'm looking in the right place, but typing "gel" in Quick Access finds "Open GEL Files view" which opens the GEL Files tab.  f28377d_cpu1.gel is listed there.

ToddMullanix said:

Can you build and run one of the kernel examples?

Yes, the first thing I did was create a New CCS project > TI-RTOS Examples > Kernel Examples > TI Target Examples > Minimal.  BTW, I can run and load at least basic code to control an LED, but it has to run from flash.  I can move a couple object files into RAM, but too much and I run into this functions not being loaded in RAM problem.

exam_controller.zip

ToddMullanix said:

I just looked in the mapfile and it shows the following functions in flash, not RAM.

0 000844f3 _log_tx_en_set
0 000844fa _log_idle_tx

Is the snapshot in the first post from a different memory layout?

Yes, that's what I meant by "Note that in this instance, the first function not loaded in RAM that I notice is gpio_init()."  Sorry, if that was not clear.

ToddMullanix said:

gpio_init should be in RAM at 0xd0af. Is _idx_bit32_calc at 0x4000?

I think you mean 0xD000?  No, idx_bit32_calc looks bogus, see below:

ToddMullanix said:

Is there anything after 0xd0af?

ToddMullanix said:

Can you attach your application? I can try it here.

I can't post it on a public forum.  I can try sending it to Zachary Stokes and ask him to forward it to you or if you have another non-public way.  I'm running on a custom board, so it'll take me a bit to check if it runs on a Experimenter Kit so you can try running it.

ToddMullanix said:

Can you modify the memory around 0xd0af manually with the memory browser?

Yes, see below.  Prior to modification the byte before, first, last, and byte after gpio_init were all zeros.

ToddMullanix said:

Strange. Can you remove the "run to main" option in CCS (Tools->Debugging Options->Auto Run and Launch Options)? Now when you load, it does not run to main(). What is at 0xd0af now?

It's all zeros, so uhmmmm...

I just realized that is the global shared RAM. Are you loading the other core also? For the first snapshot, it looks like you are not. Can you try loading the image on the second core to see if the same thing happens. Which core are you giving write access to for the global shared RAM?

Can you trying putting data into RAMGS1 instead and see if that works? (i.e. add RAMGS1 as an .ebss location in the linker file).

I'm pinging one of the C2000 engineers to see if they have any ideas also.

Out of curiosity, are you trying to put code in the RAMGS1 so it can be shared by both cores? Or are you just placing code there since you need some additional memory on the first core?

Todd

ToddMullanix said:

I just realized that is the global shared RAM. Are you loading the other core also? For the first snapshot, it looks like you are not. Can you try loading the image on the second core to see if the same thing happens. Which core are you giving write access to for the global shared RAM?

The same thought occurred to me last night.  I was not explicitly trying to load the core, though I may have been unintentionally doing so last night.  I had problems building my project and I thought .metadata was corrupted, so I deleted it then CCS defaulted to loading CPU2.  When I tried to "Reload Program" it would error out trying to communicate with CPU2 and I would have to run "Debug" again (which would terminate and restart the session).  I think I figured out how to disable loading CPU2 by deleting the field in Debug Configuration > Program > Device ... CPU2 > Program which seems to allow me to "Reload Program" again.

I'm not explicitly setting write access, but it defaults to CPU1 and I checked that was still true when I saw gpio_init() was all zeros in RAM and after it halts.

ToddMullanix said:

Can you trying putting data into RAMGS1 instead and see if that works? (i.e. add RAMGS1 as an .ebss location in the linker file).

So there is non-zero data at RAMGS1/0xD000 now:

But while gpio_init() has moved, it is still zeros:

ToddMullanix said:

Out of curiosity, are you trying to put code in the RAMGS1 so it can be shared by both cores? Or are you just placing code there since you need some additional memory on the first core?

I'm not trying to use the 2nd core right now.  Previously the project was on a single core F28069 and we switched to a dual-core for future performance headroom.  Presently, I'm just placing code there because that's where most of the RAM on the F28377D is and my code will not fit in just the much smaller local SRAM.

I have not used __attribute__((ramfunc)), but I'm also not trying to load the code into flash and run it out of RAM.  I'm trying to load and run code out of RAM.  So my linker file has this under SECTIONS:

ram_text : >> RAMGS0 | RAMGS1 | RAMGS2 | RAMGS3 | RAMGS4 |
              RAMGS5 | RAMGS6 | RAMGS7 | RAMGS8 | RAMGS9 |
              RAMGS10 | RAMGS11 | RAMGS12 | RAMGS13 | RAMGS14 |
              RAMGS15 PAGE = 1
{
// uncomment to cause function not loaded in RAM problem
// *.o28FP (.text)
// *.a28FP (.text)
// *.lib (.text)
    gpio.obj (.text)
    main.obj (.text)
    watchdog.obj (.text)
}

If I comment out the gpio.obj (.text) line, then it loads and runs out of flash just fine, but when I uncomment out the same line, I see gpio_init() in RAM, but zeros where code should be.

I have loaded code into flash, copied to RAM and run out of RAM before, but I used a slightly different method where I call memcpy() which I copied from the C2000 Microcontroller Workshop Guide Lab 12.

Here's my linker file.

TMS320F28377D.zip

ToddMullanix said:

Hold off on getting me the example if it's a pain.

It' actually wasn't a pain as I could load the project on an Experimenter Kit pretty easily to reproduce the problem.  I was actually just asking if I should forward it to Zachary Stokes to get it to you without posting my application publicly.

Anyhow, since I wasn't aware of another way to send it to you, I've emailed it to Zachary Stokes and asked him to forward it to you.  If you load the program up on an Experimenter Kit and use the Memory Browser to go to gpio_init, you should see that it's all zeros.  I suspect there is something pretty basic I'm doing incorrectly out of ignorance and I'm hoping that you will be able to identify it quickly once the application is directly in front of you to manipulate.

Thanks,

Joseph

Hi Whitney,

Thanks for the info.  I am a little confused, however.  On the F28069, the development was in RAM and when we ran out of RAM, code was moved piecemeal into flash as needed, so it seems like we were able to have CCS load parts of it into RAM and parts of it into flash.  Did this change for the F28377D?  I do notice that the flash erase is much faster.  Previously on the F28069, I would only erase/load the flash sectors that were being used to save time because it was so slow.  On the F28377D, the erasing/loading the entire flash is faster than erasing/loading a single F28069 flash sector.  Is this because the flash tools changed?  Are they are much faster now, but no longer support loading parts into RAM and parts into flash?

Best Regards,

Joseph

Hi Vamsi,

Just to be clear, the flash tools you are talking about are automatically run behind the scenes by CCS?  I have not explicitly been using any flash tools other than what CCS may be running, so I wanted to make sure we aren't talking about different things.

If flash is not used at all, are the RAM contents guaranteed to be loaded into RAM?

Anyhow, I'm surprised by this since it seems like a very important thing to know and should be documented prominently.  Can you point me to where this is documented?  I have gone through the C2000 Microcontroller Workshop - Workshop Guide and Lab Manual and I don't recall any mention of this and I would expect it to be mentioned there.  Did I miss this?  

Best Regards,

Joseph

Joseph,

1) Yes, I am referring to the Flash Plugin in CCS (Tools -> On-Chip Flash utility).  Also, UniFlash standalone programmer from TI does not guarantee RAM load.  Even third party tools like Codeskin does not load RAM.

2) If Flash is not used, yes, the RAM contents are guaranteed to load in CCS.

3) We mentioned about this in the F2837xD Flash programming support post:  

https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/314938/1138224#1138224.  

Below is the snippet from this post: 

Note on Flash programming tools:

If a COFF file has sections intended for Flash and RAM (i.e. some sections targeted for flash and some other for RAM), the flash programming tool will not load the RAM contents properly.  Hence users should map all the sections in linker command file to either Flash or RAM.  In other words, the linker command file should not have sections mapped for flash and RAM.  End-application codes will have all sections mapped to flash only and would typically copy any time critical code (or other initialization code) from Flash to RAM during run time for execution. 

In the TRM, while talking about the TI Flash tools, we mentioned that the tools are for erase/program/verify the flash content through JTAG.  I will ask the documentation team to explicitly mention that RAM contents are not guaranteed to load.  

Thanks and regards,

Vamsi  

Hi Vamsi,

Is it possible to load only in RAM w/ TI-RTOS?  I tried mapping everything to RAM in the linker file, but I still get .ti_catalog_c2800_initF22837x_flashfuncs in FLASHA.  In the Boot module, I tried:

1. disabling Configure Flash Controller
2. disabling Enable boot from FLASH
3. disabling the Boot module

All of these had not effect on removing .ti_catalog_c2800_initF22837x_flashfuncs from FLASHA.  So I can't seem to get TI-RTOS to not load something in flash, which means I have to load everything into flash.  Presently, it seems like my only hope of getting software breakpoints is to copy everything from flash into RAM at runtime.

Ok, I think I managed to get everything to load in flash and run out of RAM. I had to upgrade CGT to a newer version that supports --ramfunc=on, and copy the SECTIONS for .TI.ramfunc from a newer TMS320F28377D.cmd file. Now, I seem to have software breakpoints. I did run into a couple of issues, however:

1. Does the #ifdef/#if around the .TI.ramfunc work? I had to comment it out as it was disabling the section.

2. The breakpoints seem to behave a little odd. After loading the code, it no longer halts at the start of main() like it use to. Furthermore, breakpoints enabled prior to loading code don't seem to work. I have to add the breakpoint after it loads and runs, then I will see it break at the S/W breakpoint.

3. I had to combine all the RAMGS0 to RAMGS15 blocks into a single block since I have an object file that was too big to fit into a single block.  Are there any issues boundary/alignment with doing this?  For example instruction fetching across RAM boundaries, or DMAing across RAM boundaries?

Joseph,

Good to know that you are able to load to Flash and execute from RAM.

1) Regarding the .TI.ramfunc: Check out this post https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/535034/1947929

2) Check out CCS Debug view -> Tools -> AutoRun and Launch Options.  See whether the option to "Run to Symbol Main On a program load or restart" is enabled or not.  

Checkout the Program/Memory load options to see if the breakpoints are configured to get cleared on a program load.  

3) Should be fine to combine those RAM blocks.

Thanks and regards,

Vamsi

Vamsi Gudivada said:

1) Regarding the .TI.ramfunc: Check out this post https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/535034/1947929

Hm, that post doesn't seem to be relevant to my issue.  Sorry, I think I wasn't clear in my explanation.  The following is from the TMS320F2877.cmd:

#ifdef __TI_COMPILER_VERSION
#if __TI_COMPILER_VERSION >= 15009000
    .TI.ramfunc : {} LOAD = FLASHA | FLASHB | FLASHC | FLASHD | FLASHE |
                            FLASHF | FLASHG | FLASHH | FLASHI | FLASHJ |
                            FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0,
                     RUN = LS05SARAM PAGE = 1,
                     table(BINIT)
#endif
#endif

However, I get the following error when building it:

#10430-D ".TI.ramfunc" section generated by __attribute__((ramfunc)) or --ramfunc=on requires a SECTIONS specification to function.

I get the error because the #ifdef/#if are disabling the .TI.ramfunc SECTIONS specification.  To avoid error, I commented out the #ifdef/#if and corresponding #endif/#endif.

Vamsi Gudivada said:

2) Check out CCS Debug view -> Tools -> AutoRun and Launch Options.  See whether the option to "Run to Symbol Main On a program load or restart" is enabled or not.  

Checkout the Program/Memory load options to see if the breakpoints are configured to get cleared on a program load.

I don't see an AutoRun menu item under the CCS Debug view > Tools menu, but I'm assuming it is the same as project Properties > Debug > Auto Run and Launch Options > Auto Run Options > Run to symbol: main > on a program load or restart is checked.

Disable all breakpoints when loading a different program was checked, so I unchecked it.  I think this seemed to fix the breakpoints for a little bit, but how it's behaving strangely again.

After playing with it for a long time, I found out that the problem with breakpoints not working after a program load happens when I use --ramfunc=on.  Since this makes debugging difficult, I worked on getting breakpoints working properly.

Previously, I was not able to fit everything into RAM, but I recently figured out I was not using all the RAM.  Now everything barely fits and I have software breakpoints that work after a program load.

It is likely that the code will grow big enough so that it can no longer fit in RAM at which point putting anything in flash means putting all code in flash, then running out of RAM.  At which point, I will have to use --ramfunc=on but still need the ability to debug with breakpoints that work after program load.  Is there something I am doing wrong that breakpoints don't work after program load with --ramfunc=on?

Christopher Chiarella said:

The #ifdef isn't working because there is an error with the syntax. Change "__TI_COMPILER_VERSION" to "__TI_COMPILER_VERSION__"

Thanks, that worked.

Vamsi Gudivada said:

Regarding using breakpoints: Can you try inserting breakpoints in RAM (ramfuncs area) after you do memcpy?

Hi Vamsi,

Sorry my delayed response.  I'm not exactly sure I know what you mean by "inserting breakpoints in RAM (ramfuncs area) after I do a mempcy", but maybe I can explain what I have tried in enough detail to answer your question.

This project was originally the Piccolo F28069 and I'm trying to get it working also on the Delfino F28377D.  I was using ramfuncs only for flash configuration on the Piccolo, but for the Delfino I have disabled this and I'm using the TI-RTOS flash configuration in the Boot module instead.  So I'm not doing a memcpy for ramfuncs in the Delfino.

If you referring to .TI.ramfunc, I assuming the memcpy occurs in the boot loader when I compile with --ramfunc=on. In which case, any breakpoint after main() is called should be after the memcpy, so my breakpoints (which are all after the memcpy() in time) there don't work immediately after Debug or Reload Program.

I am doing a memcpy to copy DMA source data from flash into DMA accessible GSRAM, though this is not related to ramfuncs.  I tried putting a breakpoint after the memcpy() and it never gets hit.

Also, I'm getting the following on the console, but I'm not sure how to address it:

C28xx_CPU1: Trouble Removing Breakpoint with the Action "Finish Auto Run" at 0x12646: (Error -1066 @ 0x12646) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 6.0.407.3)
C28xx_CPU1: Trouble Removing Breakpoint with the Action "Remain Halted" at 0xfdbc: (Error -1066 @ 0xFDBC) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 6.0.407.3)

Thanks and Best Regards,

Joseph

Joseph,

What is the CCS version that you are using?  Did you install all the available updates?

Thanks and regards,

Vamsi

Vamsi Gudivada said:

What is the CCS version that you are using?  Did you install all the available updates?

Code Composer Studio

Version: 6.1.2.00015

Yes, I have installed all the available updates.

Regards,

Joseph

Hi Joseph,

Regarding the error wrt breakpoint on GSxRAM, could you check if you are able to read/write into that particular RAM from CCS memory watch window? If not then I suspect that device has not been initialized properly. To do so, you should reset the CPU and run the BOOTROM code and then re-load the code and see if problem is resolved.

Regards,

Vivek Singh

Yes, I am able to read/write to that particular RAM, specifically the address indicated by the error.

Regards,

Joseph