Debug vs Release

The fact that Debug and Release act differently indicates that they are not actually identical as you have assumed.  Have you checked that .out files and .map files are exactly the same between Debug and Release?  If the builds are identical, then there won't be any difference. 

How did you setup you Release build?  Typically a Release build uses much more optimization with the compiler than a Debug build and eliminates most if not all symbol information from the .out file.  The linker command file may change if you are using different memories between Debug and Release.  This is of your chosing and nothing is done automatically

I don't understand a few things in your post:
1. How do you boot from both CE1 and CE2.  Can you clarify?
2. Did your test program work for both Debug and Release?
3. Can you clarify your comments on code size?  I'm not sure of your point

Regards.

Hi,

To be clear - we boot from Flash located on CE1 - boot mode [2:0] = 011,  running some code in DARAM and some code in PSRAM (CE2).

Yes, the test program  to toggle the LED ran for both Debug and Release -

Yes, we did compare both Release and Debug files for the port pin (toggle) program - they were the same

Yes, we did compare both Release and Debug files for our application - they were the same

Save for the date, build time and directory i.e. Debug and Release

We run the Debug file (final application) and it works - in Debug mode - then we compiled and ran the Release out file in Debug mode and it worked.

We then used the hex55 utility

hex55 -a -boot -parallel16 filename.out -o filename.hex

We then tried

hex55 -a -boot -v5510:2 -parallel16 filename.out -o filename.hex

Bearing in mind we've been able to build, convert, and flash burn our small program to toggle a port pin.

We note the optimization fields in the Release build configuration  and ensure that both Release and Debug configuration were the same.. and we rigorously checked them by cutting and pasting the compiler and linker options-text from the setup window for both instances.

Hi TommyG,

We've had a closer look at what seems to be going on.

We have built a number of small projects to toggle port pins and managed to flash burn those to memory, and they worked .

When we came to flash our final application we saw that it would not work. We returned to our test program and looked at what sections were contained in PSRAM and what sections were contained in DARAM. We noted the flashed test program would not run when the .text was located in PSRAM. In our final application the .text program is too big to fit into DARAM.

We believe the issue rests with the command linker - whilst we can build and run in debug mode, we cannot flash our final application due to the .text file being  to big.

It seems to me that this is bread and butter stuff for TI and that there will never be an application that must run solely on internal memory. Soooo, what's required, a dual boot process? If so how does this work. We see the boot.obj is in the .text section, and suspect the problem may rest with this?

There must be some documentation that deals with programs larger than DARAM for the 5501 and how the boot process is managed - our application is around 220k, and only a small portion of this will need to reside in DARAM.

What are your thoughts,

Regards

DEV1,

Let me see if I understand your situation.  When you use Code Composer Studio (CCS) to load the program it works ok whether it is built for Release or Debug mode.  When you try and flash the program and run in stand alone mode it does not work.  Is this correct?  Also, when you put your test program in PSRAM is does not work.  Is this also correct?

When you are running from CCS there is usually a GEL script that is run when CCS first starts up that does some initial system configuration.  Do you have such a script?  It will be shown in your CCS project view.  Check to see if there is any HW configuration being done in the script that you are not doing in your application.  I am wondering if the CE2 interface is not being configured correctly prior to trying to run your application from flash.  This problem has come up in the past.  Unless you examine the GEL script you might not be aware that any special HW configuration is being done for you.  There is a Wiki article written for the C6000 family of DSPs that covers this topic.  It will not apply exactly for you, but the idea is the same.  Here is a link to the article: http://processors.wiki.ti.com/index.php/Flashing_the_C6747_EVM.

This seems the most likely cause at the moment.  Let me know if this applies in your case.

Regards.

Hi TommyG,

Thank you for your reply - yes, when we use CCS3.3 the program runs fine in Debug mode and Release mode and we do use GEL initialization for the external memory and the PLL, initialising XBSR (Even though we know it's high GPIO6 on boot - excess of caution), EMIF CE0, CE1 and CE2, and we also initialize the PLL.

We now feel that we will need to initialize the external memory CE2 in order to put code there and run it (from CE2) with the fast stuff in DARAM.

Reading through the Boot loader application note we use the following commands for the hex55 utility (please note we can compile and run a small to toggle a port pin with the .text located in DARAM - but it will not run when put into  CE2 in the cmd linker file for the project build.

-a    /* hex format */

-v5510:2

-boot /*boot */

-parallel16 /* parallel */

-reg_config 0x800, 0x0760 /* GCTRL 1 */

-reg_config 0x801, 0x0005 /* GCTRL 2 */

-reg_config 0x808, 0x0510 /* CE2 Space control register 1 */

-reg_config 0x809, 0x0150 /* CE2 Space control register 2 */

c:\Directory\Release\filename.mout

-o c:\Directory\filename.hex

-map c:\Directory\filename.mxp

What other steps and consideration do I need to make, are the command correct for the hex55 utility build, is there something I need to do with my source in CCS3.3.

Regards

Hi TommyG,

Please can you suggest a document that details appropriate time between register initialization in the boot process - there doesn't seem to be any documentation or guide lines for register configuration of the EMIF or PLL  for how long we need to wait - save for a thumb in the air "let's wait 256 CPU cycles"

Best Regards

DEV1,

The best recommendation I have is to duplicate all initialization done in the GEL file into your application initialization code.  Since the code works using the GEL initialization, it should work for you when you boot from flash.  Another point is that since you are booting from flash, I don't think you need to setup CE2 with the bootloader.  CE2 could be setup during the HW initialization routine you should run before you copy any code/data into PSRAM.  Doing the way you show makes it harder to track the initialization you are performing since it is now being done in 2 places.  Though it is not wrong to do it this way if that is your preference.

I'm not sure if your register configurations are correct just by looking at them.  Do they duplicate the configuration done in the GEL file?

Regards.

DEV1,

The only docs I know about are the Peripheral Reference Guides.  The EMIF PRG is http://www-s.ti.com/sc/techlit/sprugu6.  The bootloader manages the PLL configuration based on CLK_SEL as stated in the Bootloader App Note (http://www-s.ti.com/sc/techlit/sprabd7).  You shouldn't change that until after the boot process is completed.  Details on the PLL is supposed to be in the System Guide, but it hasn't been released yet.  To get the information you want on the PLL you should start with the System Guide for the TMS320VC5505 device (http://www-s.ti.com/sc/techlit/sprufp0a), then you need to look at this Wiki article (http://processors.wiki.ti.com/index.php/TMS320VC5504/05_to_TMS320C5504/05/14/15_Migration) to see the differences between the VC5505 and C5515 devices because there have been changes to the PLL.

Regards.

DEV1,

I think I told you wrong about not using hex55 to configure CE2.  I was thinking incorrectly that you were running from flash, when in fact you are bootloading from flash.  So, you will need to configure CE2 using hex55 .cmd as you described.  Otherwise, when the bootloader tries to write to CE2 it will not work as you have already experienced.  Sorry if this was confusing.

Regards.

Hi TommyG,

Thank you for your ongoing replies.

We have solved the issue - there were three things happening - on an aside - I honestly thought the project had been completed when it came to using the Hex55 utility - however - careful consideration was required in determining the order of register configuration, timing (-delay 0xf00) of the cmd script  and management of the cmd linker file.

After the fact, I now see all the information is available as reference material, but not as a cohesive guide - if that makes sense.

Thank you, I now see the matter as closed - save for needed documentation on minimum  cpu clock cycles required for robust register configuration in the boot mode - and this is not available and it is a critical factor in the start up process to ensure the application runs every time - presently we will never know where the edge is.

Regards