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.

C6747 and secondary bootloader problem

Hello everyone.

I have written a program for C6747 that downloads a COFF binary file from a host pc through a USB 2.0 connection (a flavor of a secondary bootloader). The host program processes the COFF file and sends the C6747 USB device the data and address  of each section to write the data. Once the data has been written to its correct place in memory, the secondary bootloader jumps to the entry address. I have been able to successfully download and run a small test binary file. However, when it comes to a much larger binary file, the program will not run after jumping to the entry address.

After jumping to the entry address of the downloaded executable, it seems to go through a c_int00 routine, however, it never makes it to the main subroutine. Should I compile and link my own c_int00 subroutine to the applicaiton to be downloaded? If so, how do I compile and link boot.c with the project to be downloaded?

Can someone give me some insight as to any additional steps that has to be done in order to get the downloaded binary/executable to run?

  • Okie,

    My guess is that some of the downloaded data is still in cache. Use L1D/L2 cache writeback commands to get it all moved to the right place and L1P invalidate to make sure the right thing gets read in.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • Greetings,

    If your PS is IRAM for a small run time and SDRAM for the large run time, then you need to have the proper init code in your boot loader before dropping your run time.

    Good Luck,

    Sam

  • Hi Randy P,

    Thank you for the suggestion. I found and read through C674x DSP Cache documentation and used the C6747 Megamodule documentation to perform the global L1/L2 cache writeback commands, L1P invalidate command, and waIted on them to complete with the following code after the new executable had been written to memory:

    *L1WB = 1;

    while(*L1DWB & 1)!=0);

    *L2WB = 1;

    while(*L2WB & 1)!=0);

    *L1PINV = 1;

    while(*L1PINV & 1)!=0);

    However, I did not get any different results than before. Did I use the commands correctly, should I do block commands after writing each block of data to memory, or did the above code possibly not work due to privilege or permissions issues?

    Thanks,

    Okie

  • Hi Sam, 

    Thank you for your response. Can you please clarify a few things.

    What does PS stand for?

    Are you implying that I should place a c_int00 routine within the bootloader code before calling the entry point or c_int00 routine of the newly downloaded executable?

    Thanks,

    Okie

  • Greetings,

    PS stands for Program Store.  When you use large app, is it going to IRAM or to SDRAM?  IRAM need no initialization.  SDRAM on EMIFA or EMIFB require init in the 2nd BL prior to loading.

    Good Luck,

    Sam

  • Sam,

    Thank you for the response! Yes, for the most part, the larger application is being loaded into SDRAM/EMIFB. Now, when you say "require init in the 2nd BL prior to loading" are you saying that there must be an initialization routine or c_int00 for the executable before it is copied to memory?

  • Okie,

    After you have downloaded the program, look at it with CCS to see if it looks right. You can learn a lot from that process. Make sure you do not have a GEL file included, though, since it can do initializations that would mask your system's initialization requirements.

    Regards,
    RandyP

  • Greetings,

    SDRAM I/F on EMIFB comes out of Reset with certain default setup.  Your 2nd BL need to ascertain you have the proper setup for you own device before you can reliably store PS/DS in it and use.  Typically in your 2nd BL, you flush the CPU critical register, init PLL, pin mux and power if necessary, then init your SDRAM I/F before you use it.

    Good Luck,

    Sam

  • Hi Randy P,

    Thank you for your response. I did have a gel file included with the downloaded executable. I removed this from the executable to be downloaded, recompiled and loaded the new executable with my downloader. However, I did not get any different results.

    I have checked out the memory in CCS. The executable is being copied to memory according to COFF parsing correctly. After the program is downloaded to memory, the downloader program branches to the enry address of the new program, the assembly code that it jumps to looks like an intc_00 or code similar to boot.c, but it never gets to the "main" subroutine of the new program. It eventually hangs in an infinite branch to the same address in memory.

    The reason I say that it nevers get to main in the new program, is because I placed code in the entry of main to initialize and turn on an led on the C6747 evm board. I have tested this in CCS before using the downloader program. It works in CCS, however, when I use my downloader program, it does not seem to get to main, because the led does not turn on.

    Does the new executable require any special initialization or custom C_int00/boot strap routine to be compiled and linked with it?

    Thanks,

    Okie

  • RandyP,

    I am basically trying to do the same thing that TI does in CCS with the Load and Run commands to load a .out file and run it through usb and a host machine. All of the sections of the .out file are being loaded correctly to memory, and it jumps to the entry address of the new program. But it is not getting to main or not running the new program.

    Is there some insight that you can give me or are there additional steps that have to be done in order to get the new executable to run on the dsp?

  • Greetings,

    Your 2nd BL should do all the init that the Gel does, under CCS control, then your app should start the same way.

    Good Luck,

    Sam

  • Hi RandyP,

    I conducted some more tests with the writeback and invalidate commands. You were right. After loading the program and running the writeback and invalidate commands, and placing the entry address in to the PC register in CCS the newly downloaded program ran.

    The way that I have my program set up is to download the program, then jump to the entry address. However, after running the invalidate command the current program function call to branch to the entry address was no longer valid. For my application, I need to be able to jumb/branch to the entry address after loading the new executable to memory. Do you have any suggestions for being able to do this without a function call within the code after the data has been refreshed with the WB and INV commands?

    Thanks,

    Okie

  • Greetings,

    I suggest you review the Gel provided by Spectrum for their L137 EVM at http://support.spectrumdigital.com/boards/evmomapl137/revg/files/evmomapl137_dsp.gel and replicate the OnTargetConect in you 2nd BL, which should reside in IRAM before you deposit any code in SDRAM.

    Good luck,

    Sam

     

  • The version of the bootloader above was written with a project that included a DSP/BIOS configuration file that handled the interrupts. I have another version of this bootloader that does not include a DSP/BIOS configuration file.

    The non-DSP/BIOS verison of the program works. It loads and runs the executable automatically without having to manually put the entry address into the PC register. However, it will only work if the executable being downloaded has a CIO section, which is only present in the download when at least a single printf statement is compiled and linked within the program.

    Is the CIO section, a required section of memory to be apart of all C6747 executables? If so, is there a way to include it in the executable without having to have a printf statement compliled and linked into it?

    Thanks,

    Okie