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.

What does ccs do after loading .out file

Hello,

I am testing my code with ccs6  and xds560v2. Device i am testing is c6671.

When I downloaded a code, I saw error message as below.

[quote]

Trouble Reading Memory Block at 0x6620676e on Page 0 of Length 0x1:

(Error -1202 @ 0x6620676C)
Device core is hung. The debugger will attempt to force the device to a ready state to recover debug control. Your application's state will be corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further.
(Emulation package 5.1.600.0)

[/quote]

I think that this error is related to my code, but I can't debug because of this error. 

However the address 0x6620676C is PCIe area I don't access at all.

I cannot debug because of this error.

If I know the sequence of .out file loading, it should be very helpful for me to find reason. 

  • Hi,

    When is that exactly happening? Is it immediately after you load code to the core or after it loads and hit F8 (Resume) to start running it? If the former, then you can simply disable the Auto-run to main and execute the initialization code (before main) step-by-step to see where the issue comes from. For details, check section 3.2 of the page below:

    http://processors.wiki.ti.com/index.php/Debug_Handbook_for_CCS

    If the latter, you will have to perform a step-by-step in your application code to find out why it is locking the device.

    A hung core means it is trying to fetch data or an instruction from a given address but it is unable to do so - it is basically waiting for the data to come in.

    Given the address is in the middle of a peripheral memory you are not using (PCIe), that explains why it is hung: it jumped to that address probably due to a rogue pointer.

    Overall, the page I sent before has a good overview of the debug launch and code loading process. Check section 2 of the page.

    Hope this helps,

    Rafael

  • Hello, desouza

    My case is former case.

    Any way, I found where the error occurred from. I wrote 8K data to DDR3 memory in main(). If I disabled that DDR3 writing routine, no error occurred.

    I tested successfully similar code before. When I tested successfully ddr3 writing before, I didn't use gel file.

    I am using gel file now for initialization and there is also ddr3 initialization and test routine.

    Can gel file give effect to main function?

    I didn't test again without gel environment yet. Just I need to know how far gel file effect.

  • Hi,

    Thanks for reporting back your findings.

    The GEL file performs several hardware initialization routines including clock, DDR and sometimes other peripherals, and therefore is critical if you intend to use one of these peripherals during the debug phase of your project.

    When you move to your product (or is in the later stages of development) you can simply copy the desired code inside the GEL (it is written in C syntax) to an initialization source file of your project.

    Hope this helps,

    Rafael

     

  • Hello desouza,

    I don't understand yet.

    I thought that GEL file initializes some peripherals just when connecting target so GEL file does not effect main function. Am I wrong? 

    In my case, GEL file looks that it is still alive after finishing initialization.

    I disabled some routine related to DDR in GEL file, but same error still occurred if I inserted DDR writing routine to main() even I unchecked auto run option.

    I will prepare bootrom later and bootrom will initialize device before starting main. Thus I just used GEL file instead of bootrom. My plan was that initializing by GEL, reading/writing by main function.

    Can't I divide code for same peripheral to GEL and main function?