• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1253 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

[C6713] debugging boot-loader code, controlling where CCS3.3 starts

tealok
Prodigy 40 points


I have a custom board using C6713B, CCS3.3 and BH USB560bp, and attempting to debug bootload assembly code.  My problem is that, from the CCS IDE, since the emulator does NOT yank on the RESET line, the boot-load code does NOT get loaded down at 0x0, and I cannot walk through the boot code.  I dearly want/need to do so.  I note that when the IDE starts, it runs the GEL file code, then jumps to _c_int00, to init the C-runtime environment, and thence to my main().  Is there any way to persuade the IDE to jump to an arbitrary location, such as my boot-load code--- which, ultimately, will jump to _c_int00?  Any help (ie, other ideas) appreciated.  jim

  • 0
    TI__Mastermind 18130 points

    Hello Jim,

    After you load CCS I strongly suggest removing the GEL file as this 'soils' the debug-from-flash experience. The GEL file will, among other things, configure some peripherals which can cause your device to behave different than it would when run on its own.

    Note that this is actually a common mistake with bootloading because the common peripherals such as EMIF and PLL are configured automatically via the GEL. If you do not include this in your application code (generally you want this inside the second-level bootloader) you may experience boot failures. For example, if the EMIF registers are all at their default values then writes to an SDRAM would fail as the default configuration is for 8-bit ASYNC memory.

    With that said, once connecting to the target through CCS the easiest way to reproduce booting from flash is to force the Program Counter (PC) to the beggining of your boot code. You can see the current value of the PC by selecting View->Registers->Core Registers, and you can modify the value by simply double clicking the field next to PC. Because the on-chip ROM from which the device boots is not directly accessible from the memory map there is no way to step through that portion; however, there are a few things you can do to get around this limitation.

    1. Put an infinite loop inside your second-level bootloader (int value = 0; while(val == 0);). Allow the device to boot before connecting through CCS and then upon connecting break the loop (force value = 1;).

    2. You can load only the second-level bootloader directly from CCS (remember to remove the GEL file) and force the PC to 0x0 which should coincide with the beginning of your second level bootloader. This would allow you to step through the code/data copies and see where the problem(s) is.  

    There's also an article on the eXpressDSP Wiki which discusses Debugging from Flash that you may find useful.

    I hope that this helps.

  • 0 in reply to TimHarron
    Prodigy 40 points

    Tim,  Thanks, very helpful !! ... but also spawns additional questions. 

    Specifically, your suggestion to put an infinite loop early in the bootloader, to give me time in CCS to attach to the target, begs the question...

    What is the minimum amount of initialization that MUST be accomplished in the boot-loader assembly code, after reset, before the CCS IDE/emulator can start interacting with the C6713?  I suspect at _least_ the EMIF, but what about the PLL?  Are the JTAG/emulation registers "ready to go" immediately after reset?

    What, problems, if any, would you anticipate if my minimalist 1st- and 2nd-level boot code looked like this? ... 

         1st-level:     init EMIF then jump (branch) to 2nd-level boot code

         2nd-level:    infinite while-loop, as you suggest, then init PLL, other critical HW, copy sections, etc,  branch to _c_int00 -> main()

    Any help will be appreciated.  Jim

  • 0 in reply to tealok
    TI__Mastermind 18130 points

    Well, technically the minimal initialization that MUST take place is 0. :-) But this would only happen if your code and data are stored inside internal memory and you do not care how slow the device runs.

    From a realistic standpoint, the EMIF initialization is probably the only thing you must take care of. The PLL, while beneficial, is not always a requirement. There aren't really any emulation registers you need to worry about, and unless you experience the problem discussed in the "CCS Crashing when Connecting" portion of the article I linked in my last post you should not run into emulation issues.

    dsp_5g said:
    What, problems, if any, would you anticipate if my minimalist 1st- and 2nd-level boot code looked like this? ...  
         1st-level:     init EMIF then jump (branch) to 2nd-level boot code
         2nd-level:    infinite while-loop, as you suggest, then init PLL, other critical HW, copy sections, etc,  branch to _c_int00 -> main()


    Hopefully you should experience 0 problems with the 1st-level boot. This is actually the bootloader located inside the mystery ROM on the device. This is what executes every time the device comes out of RESET and branches to the user's second-level boot code.

    The second-level boot code should initialize the EMIF, PLL, and any other absolutely required peripherals before copying the other data/code sections, and at the end branch to c_int00. At this point your code should run just like it does when loaded through CCS.

  • 0 in reply to TimHarron
    TI__Guru*** 125430 points

    In your system is the EMIF clocked by SYSCLK3 or by ECLKIN?  If it's clocked by SYSCLK3 then I recommend that your bootloader first setup the PLL and then setup the EMIF.  I make this recommendation because SYSCLK3 would be affected by the PLL configuration.  All your EMIF timings will change as a result of the PLL being configured if you are using SYSCLK3 to clock the EMIF.

    To further clarify the answer to some of your earlier questions the only requirement for the emulator to connect is that the CPU is released from reset.

    I like Tim's suggestion of putting a spin loop in your bootloader.  You could do something like this:

              ZERO B1

    spin:

        [!B1] B spin

              NOP 5

    This will cause the CPU to stick in a spin loop.  Once you've connected with the emulator you can open a register window and set B1 to a non-zero value and the code will then exit the spin-loop.

    Brad