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.

Copy Table for .switch Troubleshooting

Other Parts Discussed in Thread: OMAP-L138

I am using an OMAP-L138, working with the DSP (C7648) in Code Composer 5.1 using the c6x compiler tools v7.3.1 on a custom board.  I am trying to copy some code from flash to RAM, access flash for status or writing, switch it back to read mode, and then continue from flash.  Since flash is accessed after the program starts running, I am only transferring the .text, .const, and .switch sections.  All uninitialized sections are already in various RAMs.  I have a test program that seems to work for transferring the data using the TI library cpy_tbl.h copy_in function.  Part of this (without the hardware specifics) is attached.

I am having difficulty scaling up the size to my actual application from the test code.  As soon as I include code that produces a .switch section, I no longer have working code.  Unfortunately, the application is large and parts are proprietary, so I cannot post it here.  I am looking for further troubleshooting help.

The test code works with the transfers.  All caching is turned off by the GEL file, which is reproduced in another code segment.  The code runs fine when run from flash, blinking the lights.

Application code works fine when placed in RAM, including a transfer from Shared RAM to DSP RAM to mimic the transfer from flash.

Placing the application code in flash with the .text and .const sections moving also "works".  I commented out the  switch statements that were producing the .switch section jump tables, and the resulting limited behavior seemed as expected.

Placing the application code in flash with the .text and .const sections moving and the .switch section remaining in flash also "works" until I write to flash or check the status.  Then the code is lost, as the jump table is gone from view.

I have tired creating a table directly from the .switch section and renaming the section to .copy_switch.  The behavior is the same; the application does not function.  I have two board LEDs set to change when the hardware setup passes control to the application, and when the application starts, exits, or changes state.  When the .switch is included, the application is never able to change the lights.

I would appreciate any other troubleshooting tips or location combinations to help get past this wall.  (I also have a similar thread with no activity on it.)  Is there any way to suppress the creation of this section with EABI?

  • As an update, I have a function with a large switch statement and a reset function that both affect a file global variable in a file.  While my other code does not call the large switch function (commented out) it does call the reset, causing the object file to be included in the link step.  It is at this point, when the file with the switch is included without being called, that the code stops working.

    The object with the switch only appears in .neardata, .switch, and .text in the memory map.  There is a smaller switch statement in the code that when included does not cause problems, or create a .switch section.  I tried moving the switch statement file to the test code, and the test code still runs.  The memory maps look similar, showing the section moving from flash to ram.  There is no trampoline required, since I have another function in RAM making the call, just like in my application.

    Since the application works as a whole from RAM, and the file that is apparently breaking it works in isolation, I will slowly build back up to my full application.  Any help in other directions to try would be appreciated.

  • Attached are the relevant test files and the two memory maps.  The main difference I could see was the .text, .cinint, and .ovly were grouped into the same flash section in the large memory model, whereas .text was a separate entry in the small model, with .cinint and .ovly grouped together following (around line 30).  The binary image I am loading in each case is the same size, so it only appears to be a link error.  Was there an issue like this addressed in any of the linker updates since 7.3.1?

    3007.Switch.zip