Is there a way to trace *.bin file boot problem on C5535 based application?

Hi Jun

The contents of your cmd file look correct. I don't see any issues there.

How are you programming the bin file to your target?

Jun Cao said:

I verified that

* The V2EP0Test.bin was correctly write to the flash memory

* Observe the LED display (on my application board), the code was loaded and run

* It seems the C5535 DMA does not response / active.

You confirmed that the bin file was flashed correctly and the LED display is behaving correctly when running? And that it is just the DMA that is not behaving as expected?

Thanks

ki

Hi Ki

Our application is a two CPU / DSP system.  CPU1 can write DSP bin file, V2EP0Test.bin , into flash and boot DSP from flash.

* CPU1 read back the flash contents and save it to a binary file which matches the original bin file, V2EP0Test.bin

* I Used Emulator to load V2EP0Test.out file into memory.  Manually checked the memory block contents and verified the contents matched the V2EP0Test.bin file assigned memory data.

Using USB560M emulator to load V2EP0Test.out into memory and run will automatic first run GEL file.  On the other hand, boot from Flash will direct load code from flash to memory and run without call any GEL file function.  Will this caused any differences?  Below are the screen display of called GEL functions:

Launch Target configuration  showing:

C55xx: GEL Output:

StartUp()

C55xx: GEL Output:

GEL_MapOn()

C55xx: GEL Output: GEL_MapReset()

Connect target  showing:

C55xx: GEL Output:

OnTargetConnect()

C55xx: GEL Output:

GEL_MapOn()

C55xx: GEL Output: GEL_MapReset()

C55xx: GEL Output:

OnReset()

C55xx: GEL Output:

SystemCleanup()

C55xx: GEL Output: Reset Peripherals is complete.

C55xx: GEL Output: Target Connection Complete.

Load V2EP0Test.out showing:

C55xx: GEL Output:

OnPreFileLoaded()

C55xx: GEL Output:

SystemCleanup()

C55xx: GEL Output: Reset Peripherals is complete.

C55xx: GEL Output:

OnRestart()

C55xx: GEL Output:

SystemCleanup()

C55xx: GEL Output: Reset Peripherals is complete.

Also I am lookinmg for a way to trace this *.bin file boot problem on C5535 based application.

Thanks!

Jun

Ki and All:

I have read your paper of “Creating Device Initialization GEL Files”.  But I still could not figure out why my application built V2EP0Test.out can be loaded and ran correctly (through TI CCS - USB560M JTAG Emulator – C5535 based application board) while the generated V2EP0Test.bin file failed to boot (loaded and ran) from flash.  I believe during the process of boot C5535 board (reset C5535, then release c5535 reset pin to boot it from flash) all the C5535 registers and peripherals already been reset.  Is that correct?  Do I need to add some additional reset code in my application code?  I guess when boot from flash the DMA does not work in the application. 

* What are the differences between run V2EP0Test.out file from CCS-Emulator and boot V2EP0Test.bin file from flash in C5535 based board?

* Do you have any suggestions to make sure the C5535 DMA will not be blocked?

* Again, is there a way to trace this bin file boot problem?

Thanks!

Jun

Jun Cao said:

I believe during the process of boot C5535 board (reset C5535, then release c5535 reset pin to boot it from flash) all the C5535 registers and peripherals already been reset.  Is that correct?  Do I need to add some additional reset code in my application code? 

That sounds right to me but I am hardly an expert on this. I'll try to get some confirmation.

Jun Cao said:

* What are the differences between run V2EP0Test.out file from CCS-Emulator and boot V2EP0Test.bin file from flash in C5535 based board?

There are many

1) GEL file is one. If you are using a GEL file, it can do a lot of target initialization (which we discussed already)

2) CCS itself with do some various actions like run to main on program load and setting various breakpoints  needed for debug. It is also possible for CCS to do auto-resets also.

3) CCS will read symbolic information in the out file to determine where to load the program and data on the target.

What I suggest is to try to debug the program you have in flash. You can hook the debugger to the target and load just the symbols for the program in flash (see slides 63-66 of the C2000 fundamentals workshop slides for an example). This can help with some debug visibility (depending on the level of optimization of the flashed code).

Jun Cao said:

* Do you have any suggestions to make sure the C5535 DMA will not be blocked?

I am not experienced on the 5535 to offer any good suggestions. I would try the C55x forums. The experts there can offer better suggestions.

Jun Cao said:

* Again, is there a way to trace this bin file boot problem?

As mentioned above, try debugging the code in flash.

thanks

ki

Hi Ki:

Thank you very much for answering my questions.

I looked “slides 63-66 of the C2000 fundamentals workshop slides”.  In my understanding, that slides talked a different cases from mine.

This slides talk about how to use CCS debug the existing code flashed on the target.  The code flashed on the target has the same meaning as the code loaded on the target.  I have no problem to use CCS to load code to target and debug it. 

My question is “why my application built V2EP0Test.out can be loaded and ran correctly (through TI CCS - USB560M JTAG Emulator – C5535 based application board) while the generated V2EP0Test.bin file failed to boot (loaded and ran) from flash.”   The V2EP0Test.bin file has been written to flash memory.  When reset target C5535 DSP.  The DSP on-chip boot loader will load the code from flash memory into DSP on-chip RAM; then further run the code.  So far I have no way to trace this boot process.  I am looking for suggestions, reference documents, …

Thanks!

Jun

Jun,

I'm looking into

Here is some very good information about the boot process and how to configure to read in from Flash for C5515. These devices are very similiar and this should give you more detail. http://processors.wiki.ti.com/index.php/C5515_Boot-Image_Programmer 

Since the DSP atuomatically cycles endlessly, i'm not sure if there is a way to intervene this process.

Could you tell me specifcally which time of Flash we are using for boot, is it Spi Serial Flash?

In hopes of redirecting this question to a more suitable section of the forums, i'm moving this to the C5000 forum.

Best Regards,

Nic

If your code (.out) file execute correctly in CCS environment; and part of your code is to blink LED and it is working in flash; then the .bin file is most likely programmed correct in the flash. As staed in this wiki page: http://processors.wiki.ti.com/index.php/C5515_Boot-Image_Programmer

Common Mistakes in Boot Image User Code

A frequent issue is that the user code works fine in CCS environment but fails to work after converted to boot image. This is most likely because the user code relies on a GEL file in the CCS environment to initialize and setup PLL. This is easily corrected by not using GEL in CCS environment, but instead including all the necessary initialization steps in the user code. It is a good practice to re-initialize everything you need from within your bootloaded user code.

Another common mistake is allocating program code to SARAM31 memory. The bootloader writes to SARAM31 (byte address 0x4E000 – 0x4FFFF) thus any user code residing in SARAM31 will be corrupted. Do not use SARAM31 if you intend to convert this code to a boot image. Once the bootloader has finished loading the program into RAM, SARAM31 can be used.

Regards.

Steve, Nic, Ki:

Thank you all for answering my questions and providing me useful information.

Though I still have no way to trace the boot process, I identified the exact problem.

Our two CPU I2S communication works as:

Data in memory - DMA - I2S interface - transmitting / receiving data to /from another CPU.

It works well under CCS - Emulator's control.  However, (when generated the bin file and wrote it into flash), the corresponding bin file boot from flash did not work.  Further investigate found the problem was DMA did not work when boot from flash.  (I have done an experiment: let DSP direct feed data to I2S interface to transmit / receive data to /from another CPU.  The corresponding bin file boot from flash worked well.)

Thanks!

Jun

Here is something to try:

(1) Remove the use of or simply the gel file used when you connect to the target with your emulator. For example remove any thing that sets up the PPL, clock gating etc. The gel setup i typically use for the 5535ezdsp for example only has Gel_reset( ) and Pheripheral_Reset( ) within the OnTargetConnect( ) function, nothing else.

(2) Load your .out file, run and see if the emulator method still works.  By doing so, you are validating that the functionality in your application's .out is taking care of everything that the gel file is doing, so that you know for sure it is a bootloader issue and not an application issue.

Other things to check:

(1) Double check your peripheral clock enabling at your application startup, the bootloader when done will disable most clocks.  It could be that the clocks for the periph you are using with the DMA are not turned on.

(2) Check  your .map file to verify that no initialized sections are in the SARAM31 block mentioned before (origin 0x04e000, length=0x2000)

(3) you should be able to launch the bootloader process using the emulator by connecting the emulator, do a CPU RESET, which should take you to the boot loader, load the symbol table ONLY of the .out file that is in the bin image, and then do an EMULATOR RUN.  At this point the application in the bin image will be running and if you halt your emulator you can look at memory, sys registers etc.  I haven't used this approach in a while, but I think you can still do it with CCS v4/5 and the built in emulation.

-S

Shawn:

Thank very much you for the help.  I really like your idea and agree with you.  In fact before saw your email I already did following:

1. Our application does not use PPL.  The gel file I used was based on eZdsp5535 gel file but deleted the PPL in two places.
2. I do suspect that the DMA clock was not turned on when boot from Flash (though my code did turn DMA clock on together with other peripheral clocks).
3. My link command file has below arrangement: 

  SARAM2 (RWIX): origin = 0x040000, length = 0x00FE00  /*  64KB */

  VECS   (RWIX): origin = 0x04FE00, length = 0x000200  /*  512B */

  PDROM   (RIX): origin = 0xff8000, length = 0x008000  /*  32KB */

Do I need make some changes to absolutely guarantee that “no initialized sections are in the SARAM31 block mentioned before (origin 0x04e000, length=0x2000)” or just make the initialized sections do not use SARAM2.

Your last point (3) is the method I looking for.  But I doubt if CCSV4 or CCSV5 really let me to do it.  In fact previously I tried below steps:

1. Using CCSV4 / CCSV5 – USB560M to connect to C5535 based target.
2. Load *.out file into C5535 based target
3. Run (from CCSV4) or Free Run (from CCSV5)
4. Reset C5535 based target manually or by another CPU IO port to boot from Flash
5. Halt – I expect at least CCS would stop C5535 and let me see what had been loaded into the memory from Flash.  However, this Halt broke the connection to the target I even can not look the memory contents.

If you can do some experiment on this point (3), please let me know.  That will be very helpful.

Regards,

Jun

I think you need to relocate your VECS section, that is an initialized section that is in the SARAM31 block.

Here is a typical linker command file setup I use. In my memory setup the SARAM3 section is the one that I avoid putting any initialized sections in:

MMR (RWIX): origin = 0x000000, length = 0x0000c0 /* MMRs */
DARAM0 (RWIX): origin = 0x0000c0, length = 0x00ff40 /* 64KB - MMRs */
SARAM0 (RWIX): origin = 0x010000, length = 0x010000 /* 64KB */
SARAM1 (RWIX): origin = 0x020000, length = 0x020000 /* 128KB */
SARAM2 (RWIX): origin = 0x040000, length = 0x00DE00
VECS (RWIX): origin = 0x04DE00, length = 0x000200
/*do not use SARAM3 for any initalized data if you plan on booting. */
/* for debug using the emulator it may be necessary to put intialized data out there */
SARAM3 (RWIX): origin = 0x04E000, length = 0x002000
PDROM (RIX): origin = 0xff8000, length = 0x008000 /* 32KB */

I have sucessfully booted a 5535ezdsp using the SD flash using the above memory map.

-S

Shawn:

Thank you very much for the help.  Tomorrow, I will relocate the VECS section in my link command file and let you know the results.  Below I list what I will do for this VECS section change.  Please check and let me know if I missed any thing.

1. In link *.cmd file include below two lines:

VECS (RWIX): origin = 0x04DE00, length = 0x000200

vectors  >  VECS                  /* Interrupt vectors           */

1. In code set the vector table by IRQ_setVecs((Uint32)(&VECSTART));
2. vectors.asm has below vectors  related arrangements

        .sect "vectors"

        .align  256

                .global _VECSTART       

;***********************

 _VECSTART:

RST:          .ivec    reset_isr, USE_RETA   ; Reset / Software Interrupt #0

1. In code set the DMA service routine by IRQ_plug (DMA_EVENT, &DMA_isr);

Please check and let me know if I missed any thing

By the way, when use CCS –Emulator to connect C5535 target, I often saw below errors:

C55xx: Trouble Reading Memory Block at 0x27f20 on Page 1 of Length 0x2c0: (Error -1143 @ 0x28000) Device memory bus has an error and may be hung. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Release 5.0.429.0)

What caused this error?

What this error mean?

 Jun

When you moved the VECs section in your linker command file did you also shorten the SRAM2 section?  This will guarantee nothing gets placed in the SRAM31 block so you can at least rule that out completely.

SARAM2 (RWIX): origin = 0x040000, length = 0x00DE00
VECS (RWIX): origin = 0x04DE00, length = 0x000200

Incidently I just ran a quick test where I booted an application with the micro SD card on the ezdsp and was able to connect it with the emulator, re-initate the boot process and pause/debug the booted code.  Here are the steps that worked for me on CCS v4.2 using the built in emulation of the 5535 ezdsp.

1. Open CCS but leave the USB cable disconnected from the ezdsp.
2. CSS: Build the code. (Will create an "App.out" and a bootimg.bin file.)
3. Copy the bootimg.bin file to the SD Card.
4. Insert sd card into ezdsp.
5. Connect USB cable to the ezdsp (ezdsp will boot the program in the sd card).
6. Give it a few seconds to boot/launch the program.
7. CCS: Target\Launch TI Debugger
8. CCS (DEBUG Perspective): Target\connect Target
9. CCS (DEBUG Perspective): Target\CPU Reset
10. CCS (DEBUG Perspective): RUN (program boots again)
11. CCS (DEBUG Perspective): HALT (ignored warnings about trouble halting cpu)
12. CCS (DEBUG Perspective): Target\Loadsymbols (pick the matching .out file of the code burned into the SD)

I can now look at variables, CPU registers, even set a break point in my code.

-S

Shawn:  Yes, I did.   Below is my whole link file.  Thanks!   Jun

Shawn:

Is it possible for you to do this experiment on *bin file boot from a Flash.  Thanks!

Jun

No, but it shouldn't matter whether you're booting from SD or Flash, the core steps are the same, connect to the device, reset, run, halt, load a symbol table.

What happens when you try the steps I mentioned on your HW?  (By the way is your hardware an ezdsp or a custom board?)

-S

Shawn:

I just came back from a meeting.  To my great surprise, follow your instructions I was able to load code from Flash (by sending Reset command from CCS).  Then run, halt, Target\load symbols from the matching *.out file, set break point, check the DSP registers.  That let me fully trace the code from flash.

The only bad thing is “every thing worked well”.  I cold not find out why direct boot and run from Flash (without any CCS operation) would fail (most likely failed on DMA operation).

This experiment convinced me that the code load from Flash is the same as load from CCS-Emulator.  Some how, the “CCS run” caused the difference.  What do you think? Any guess, suggestions, ideas from you will be highly appreciate.   You are the expert!

Thank you very much!

Jun

Try to keep pairing down what the gel file is doing on the target connect and the reset operations.  These are functions that are automatically executed with different ccs operations:

/* StartUp() - Executed whenever CCS is invoked */

/* OnReset() - Executed after Debug->Reset CPU */

/* OnRestart() - Executed after Debug->Restart */

/* OnPreFileLoaded() - Executed before File->Load Program */

/* OnFileLoaded() - Executed after File->Load Program */

/* OnTargetConnect() - Executed after Debug->Connect */

In Startup( ) just do the memory map initialization and nothing else.

in OnTargetConnect( ), try removing eveything except GEL_Reset( ) (don't call the Peripheral_Reset( ) function ).

In OnReset( ), do nothing.

This might help you get closer to the state of your board at power up.

Also, if you are using a JTAG emulator (not the built in USB emulator), pair down the OnTargetConnect( ) function, and then repeat the connection sequence but after Step 8 of my sequence, go directly to step 12.  The emulator should halt the CPU/PC right where it was when the program was executing (No need to steps 9-11).  This should give you a better picture of whats going on with the code as it ran right after booting.

Shawn:

I modified the Gel file as you mentioned.  When I launch TI Debugger I saw the GEL out put display changed / simplified.  CCS console gave me some error massage such as "Trouble Reading Memory block at 0x27f20 ...". But the final run the boot loader loaded code was correct.  Therefore, I still could not find what was missing / wrong when direct boot from Flash without any CCS operation.

Thanks!

Jun

Were you able to try the approach of looking at the SW state right after the Emulator connect (without an addtional RESET, RUN). New steps (modified from my previous post):

1. Open CCS but leave the USB cable disconnected from the ezdsp.
2. CSS: Build the code. (Will create an "App.out" and a bootimg.bin file.)
3. Copy the bootimg.bin file to the SD Card.
4. Insert sd card into ezdsp.
5. Connect USB cable to the ezdsp (ezdsp will boot the program in the sd card).
6. Give it a few seconds to boot/launch the program.
7. CCS: Target\Launch TI Debugger
8. CCS (DEBUG Perspective): Target\connect Target
9. CCS (DEBUG Perspective): Target\Loadsymbols (pick the matching .out file of the code burned into the SD)

I think with the jtag emulators, when you perform step 8 above, the cpu should be halted where it was running and at this point you can load the symbol table.  At step 8 check the value of the PC and see if it looks like its in your program space (not the bootloader).  At this point you've halted the execution of the code as it was launched by the bootloader and will hopefully provide more clues as to why the dma operations are not running.

Shawn:

I tried your new steps.

Once did step 8 – connect target, the PC value showed up.  PC pointed to the C5535 on-chip boot loader, 0xFF570E.  Is this the boot loader entry point?

Then I did your step 9 – Load symbols.

After that I was able to do CCS step, run, halt, and see the CCS run into my application code.  This way I was able to use CCS full debug functions to trace my code, check registers and code variables.  Your instructions provide a way to trace code from boot loader to user’s application code.  That is great! 

My problem is every thing worked out correctly using your way to trace it – I still could not figure out why my code failed on DMA operation when direct boot from flash by the C5535 boot loader.  I verified that when let the DSP handle the job without DMA, the code can direct boot and run from flash correctly.

Thanks!

Jun

Shawn and All TI experts:

I have two questions:

1.  Is the address of 0xFF570E C5535 on-chip boot loader entry point?  Can I get the C5535 on-chip boot loader source code?

2. When I do the step 9, CCS (DEBUG Perspective): Target\Loadsymbols (pick the matching .out file of the code burned into the SD), mentioned by Shawn, what are the CCS internal operations?  Will this operation also load the application code into the target memory.

The bottom line is I worried about some how the on-chip boot loader did not load the code (assigned by the *.bin file) into memory correctly.

Thanks!

Jun

Jun

Question 1: On my evm the PC returns 0xFF570E on system restart/Pause as well. I believe this is the bootloaders entry point. What kind of information would you be looking for in the on-chip bootloader source?

Steve, can you confirm this?

Question 2: The debugger deletes any previously loaded symbols from the symbol table maintained on the host. The symbols in the symbol file are then loaded into the symbol table. Symbols are loaded at the code and data addresses specified in the symbol file. This command does not modify memory or set the program entry point.

In addition, a offset can be applied in the same load symbols pop up when loaded. You can also specify a code offset and a data offset that the debugger applies to each symbol in the specified symbol file. For example, if you have a symbol file for an executable that contains code addresses starting at 0x100 and data addresses starting at 0x1000. However, in the program loaded on the target, the corresponding code starts at 0x500100 and the data is located at 0x501000. 

Nic

Regarding Question 2, Nic is correct. One small additional note is the option to Add symbols instead of Load. 'Load' will remove and previously loaded symbols before loading. 'Add' will not (it will simply add symbols to the existing information).

Thanks

ki

Nic and Ki:

Based on your answer to my question 2 – Loading application *.out code symbol does not modify the memory, the memory contents I saw was truly loaded by the C5535 on-chip boot loader.  That is an important conclusion for me to analyze current boot problem.

I still wait for some one answer my question 1:  Is the address of 0xFF570E C5535 on-chip boot loader entry point?  Can I get the C5535 on-chip boot loader source code?

Thanks a lot!

Jun

I have 0xFF570E with my c5535 ezDSP also. I am waiting for the bootloader designer to confirm.

Regards.

Jun Cao said:

Based on your answer to my question 2 – Loading application *.out code symbol does not modify the memory,

Yes this is accurate.

Jun,

Can you confirm that you tried Shawns comments bellow?

Shawn S. said:

(1) Remove the use of or simply the gel file used when you connect to the target with your emulator. For example remove any thing that sets up the PPL, clock gating etc. The gel setup i typically use for the 5535ezdsp for example only has Gel_reset( ) and Pheripheral_Reset( ) within the OnTargetConnect( ) function, nothing else.

(2) Load your .out file, run and see if the emulator method still works. By doing so, you are validating that the functionality in your application's .out is taking care of everything that the gel file is doing, so that you know for sure it is a bootloader issue and not an application issue.

When running without the GEL file should simulate the same actual use when running it from flash. Clearly stated, this should run the same without CCS interventions/Debug.

If it runs unsuccessfully then you may have to reinitialize parameters that were set in the GEL file.

Nic

Nic,

Just a quick comment. From what I understand, Jun has done those two steps I suggested. Additionally, he was able to sucessfully run the image from flash but only by connecting to the target and re-launching the boot loader sequence via the emulator.  It seems the stumbling block here is to be able to connect to the target after it has unsucessfully launched the flash image and prevent the emulator connection from performing the inherent RESET operation that is bringing him back to the bootloader. i.e. we want to connect to the device and freeze the PC where it is, load the symbol table, and look at variables and registers etc.  I've tried a quick attempt at this on my ezdsp, removing everything from the gel file OnTargetConnect( ) except the GEL_Reset( ) function, but when I connect to a ezdsp running an already launched app, I always find my PC at the bootloader location.  I haven't had the chance to try this on a different board using a JTAG emulator to see if the results can be different than when using the onboard emulation. So I think the question boils down to a tools question: how can we connect to a target with the emulator and just freeze the PC where it is without performing some implied RESET function.  Are there settings that we should be aware of on the connection ccml view of CCS?

-S

Jun,

Can you provide a post with your gel file attached?

Also another slightly modified approach to try with the emulator and your hardware with the app burned in:

1. Open CCS but leave the USB cable disconnected from the ezdsp.
2. CSS: Build the code. (Will create an "App.out" and a bootimg.bin file.)
3. Copy the bootimg.bin file to the SD Card.
4. Insert sd card into ezdsp.
5. Connect USB cable to the ezdsp (ezdsp will boot the program in the sd card).
6. Give it a few seconds to boot/launch the program.
7. CCS: Target\Launch TI Debugger
8. CCS (DEBUG Perspective): Target\connect Target
9. CCS (DEBUG Perspective): Target\Loadsymbols (pick the matching .out file of the code burned into the SD)
10. RUN  (skip the CPU RESET step)
11. Once you give it a chance to boot/run, HALT and inspect registers, variables etc.

Maybe the above approach will better mimic behavior after booting.

Incidently, the CPU initialization that I do in my working booting example is as follows (I think its exactly what's in some of the ezdsp examples:)

Int16 EZDSP5535_init( )

{
CSL_Status retValue=CSL_SOK;
/* Enable clocks to all peripherals */
CSL_SYSCTRL_REGS->PCGCR1 = 0x0000;
CSL_SYSCTRL_REGS->PCGCR2 = 0x0000;

/* setup the PLL*/

retValue=(Int16) PLL_Setup();
return(retValue);
}

Shawn:

You gave me the instructions to do experiments; reviewed my experiment feed back; clearly summarized the key point – “we want to connect to the device and freeze the PC where it is, load the symbol table, and look at variables and registers etc.”  You did the experiments on ezdsp with on-board emulator, I did the experiment with CCSV4 –USB560M Emulator – C5535 based application board.  I saw the same situation as you said, “when I connect to a ezdsp ( C5535 based application board in Jun’s case) running an already launched app (by boot loader), I always find my PC at the bootloader location.”

“It boils down to a tools question: how can we connect to a target with the emulator and just freeze the PC where it is without performing some implied RESET function.  Are there settings that we should be aware of on the connection ccml view of CCS?” 

By the way, I already did experiment of “skip the CPU RESET step” before I saw your latest instructions.  I saw load symbols also caused some differences as below:

Case 1.  After connect target (the PC point to 0xFF570E), do a “CCS run”, my application DMA operation would fail.

Case 2.  After connect target (the PC point to 0xFF570E) and further load symbol, do a “CCS run”, my application worked well include DMA operation.  That is why I asked “will the loading symbol also modify memory contents?” in my previous email.

Nic: 

I appreciate you moved my initial email and the answers to “C5000 Ultra Low Power DSP”.  Could you please further put all the discussion thread together from beginning to the latest?

Thanks!

Jun

Jun

For Case 1 that you listed above, I think you've essentially created the situation you are trying to get to.  In Case 1, after "my application DMA operation would fail", HALT the CPU (note where the PC is) and load the symbol table (this should not change the PC) and you should be able to look at state of your application.

If the PC does change when you are doing a load symbols, check your gel file for functions, OnFileLoaded( ), OnPreFileLoaded( ) make sure they are empty.

In your situation where "my application DMA operation would fail", are there other indicators that seem to say the app is running (I think you mentioned something about an LED blink in previous posts.)

Jun,

I was finally able to create the situation you are trying to reach with the debugger.  Here is the key:

REMOVE all calls to GEL_Reset() within your gel file.

I essentially made OnTargetConnect( ) an empty function and was able to halt a previously launched executable, load its symbol table and look at variables, set breakpoints etc.

Here are the steps (very similar to what was described before)

1. Open CCS but leave the USB cable disconnected from the ezdsp.
2. CSS: Build the code. (Will create an "App.out" and a bootimg.bin file.)
3. Copy the bootimg.bin file to the SD Card.
4. Insert sd card into ezdsp.
5. Connect USB cable to the ezdsp (ezdsp will boot the program in the sd card).
6. Give it a few seconds to boot/launch the program.
7. CCS: Target\Launch TI Debugger
8. CCS (DEBUG Perspective): Target\connect Target  (make sure you've modified your gel file to remove GEL_Reset( )
9. At this point the PC should be in your application space (not at the bootloader)
10. CCS (DEBUG Perspective): Target\Loadsymbols (pick the matching .out file of the code burned into the SD)
11. Inspect registers, variables etc, set breakpoints.

I can't believe I didn't think of this before. I thought the GEL_Reset( ) was just for the CCS side of things, didn't realize it was issuing a CPU RESET.

-Shawn

HI    Jun

    I have the same problem with you;I do the steps just like you do above and everythings do well when we connect the board to the CCS.But when I disconnect the board from CCS and power on the board again,the program doesn't work again.Do you resolve this problem?

Hi G. D,

I have not solved the mentioned problem yet.  I suspect the problem is tools or application board related.

Are you also using TI C5535 DSP?  What is your CCS Version, Emulator model and the target board?

Thanks!

Jun

Jun,

I think the key to figuring out what is going on is what you observed in steps 2, 5 & 6 in your post from May 10.  I have a couple of questions.

In step 2, was the code working correctly? i.e. was the DMA running as you expected? 

In step 5, how exactly did you reset the DSP?  Was it with the emulator RESET command or was there a physical HW reset? If it was a physicall reset, there might just be some timing issues between the CPU reset and maybe some other devices in the system like the codec or something.  What are you using the DMA for? Is it talking to a periph?

Step 6 is the most important, In this case you have halted the CPU and you see that the DMA is "stuck", which is the exact condition you are trying to debug. In what manner is it stuck? What values are in the DMA IFR, what values do you see in CPU Register IFR0. What event is it waiting for?  Were there any sucessful transfers before it got stuck (maybe add some observation counters in your DMA isr). 

-S

Shawn:

Our application is a two CPU system.  One CPU uses TI C5535 DSP doing information detection.  The other CPU act as cell phone to transfer information to the server.  We call that CPU system as BB (Baseband).  The problem is involved in the two CUP communication as below.

C5535 DSP code (Memory -- C5535 DMA3 Channel 0 -- C5535 I2S1 Slave)  -- BB (act as I2S Master)

Each time doing “C5535 DSP --  BB” communication, the code needs first to do handshake to synchronize the operation.  We can control BB side code to let DSP code stop in specific place. I use the LED to display the system initialization and communication handshake status.  

To be clearly describing my case I put your questions and my answers in line of my experiment steps:

1. Let my configure file using an Empty_ezdsp5535.gel (use  empty gel functions):

2.  After did your instruction step 1-8, CCS connected the target, my application code stopped running and the PC was in my application space (not at the bootloader), I can also saw DSP registers has the correct contents.

[Shawn] was the code working correctly? i.e. was the DMA running as you expected?

[Jun]  I believe the code ran correctly.  I use the LED to display the system initialization and communication handshake status.  I also checked the DSP registers.  They have the correct contents.  I control the BB handshake code to let DSP waiting in the place and the DMA did not start yet.

3.  Further did CCS (DEBUG Perspective): Target\Loadsymbols; I was able to trace code, every thing worked well – again could not find the boot problem.

4.  Stop the running code; change the PC to 0xFF570E; do “CCS run”.  Again, every thing work well.

5. Stop the running code; reset DSP (let DSP reset pin goes low then high), the DMA operation failed.

[Shawn]  In step 5, how exactly did you reset the DSP?  Was it with the emulator RESET command or was there a physical HW reset? If it was a physicall reset, there might just be some timing issues between the CPU reset and maybe some other devices in the system like the codec or something.  What are you using the DMA for? Is it talking to a periph?

[Jun] I sent AT command to BB asking BB to resret DSP.  BB uses its general purpose IO port to hold DSP reset pin low for a while, then release it to boot DSP (the C5535 on-chip bootloader loads and runs my test code from flash).

6. Continue from above 5.   Do “CCS halt”; then manually change the PC to cursor to get out of a dead waiting loop (because DMA had no action or did not finish); do “CCS run”.  Again, every thing work well again.

[Shawn] Step 6 is the most important, In this case you have halted the CPU and you see that the DMA is "stuck", which is the exact condition you are trying to debug. In what manner is it stuck? What values are in the DMA IFR, what values do you see in CPU Register IFR0. What event is it waiting for?  Were there any sucessful transfers before it got stuck (maybe add some observation counters in your DMA isr). 

[Jun]  You are asking the key issues.  The C5535 DMA supposes to move 32 double words (128 bytes) data to I2S to transfer to BB.  When I halted C5535, I saw the first double words (4 bytes data) has been moved to I2S register for transfering and the DMA source counter increased by 4 bytes.  The BB side did get the first 4 bytes data. Since the DMA did not finish the designed 128 bytes, there was no DMA interrupt, DMA IFR is not set.   There is a flag set by the DMA interrupt service routing.  the main loop kept checking that flag and could not come out of the loop. On the other side, the BB as the I2S master, it finished the receiving though the C5535 did not provide the correct data.  BB will continue for next handshake and data receiving.  By this time, I did above “Step 6” (halt; change PC value; run;)

It seems there is a difference between running from 0xFF570E by CCS and running by reset DSP RESET Pin without CCS control.

Thank you very much for your great help!

Jun

Jun,

Thanks for the details. Just a couple of quick comments for you.  It seems the DSP side dma is stuck in mid transfer because it is either waiting for the I2S Tx ready event or it missed one. The Tx ready event which drives the dma transfer is an edge triggered event which not latched, if a new TX ready comes in before the DMA has finished its single transfer operation, the DMA may stall out. Once in this state the DMA is stuck and will continue missing Tx ready events.  So even if the master continues clocking data from the DSP I2S, the dma will not react.  (I am assuming that the CPU side is still driving the I2S clocks when it is in the "stuck" mode).  When you are in this stuck mode, look at the I2S status registers to see what the state the I2S is in, see if from its view point it is done with its transmission.

The point that the first 4 bytes that the CPU received were garbage indicates that there may have been some "latent" Tx event that occured when the dsp came out of reset or when the I2S was first initialized, causing an early Tx ready event that might be getting triggered in the middle of the first DSP side DMA transfer.

You might need to add some "prime the pump" type logic to the DSP side (or both sides), to flush out the existing value that might be in the DSP I2S Tx, or to get the first transfer going.  Also double check that when the CPU side is reseting the DSP its keeping the I2S lines quiet.  Another thing to try is to slow down the bit clock generated by the CPU master, so that the DMA will for sure have time to do complete single transfer operation before the next Tx ready event comes in.

I know none of this explains why it works on a warm reset vs the CPU driven reset, but it just a few things that came to mind

-S

Shawn and Nic:

Thank you for keep giving me advices and test ideas. Now you both know more detail about my test cases.  Here are some additional code implement details using DSP to BB data transmitting as an example.

Memory data -> C5535 DMA -> C5535 I2S Slave to transmitting data;

BB (another CPU) as I2S Master provides bit clock and word clock to receive data from C5535 I2S Slave.

C5535 will first do hand shake with BB.  Before send the last hand shake signal to BB, C5535 will reset I2S data registers; clean possible hanging DMA interrupt event; reset DMA starting source address; enable I2S transmitting; enable DMA. That is making I2S and DMA in a ready state to work with the bit clock and word clock sending by BB.  Only at this stage, C5535 will send out the last hand shake signal to BB.  Once received the last hand shake signal BB as Master will start the data receiving.

Today I further found only need CCSV4 to connect the target C5535 board, my test code boot from flash will work.  Below are the steps I did.

1. Write my test.bin file into C5535 target board Flash.
2. Run BB code to the beginning of handshake code, and halt there.
3. Use BB IO port to reset target board C5535 to boot the code from Flash.  Because of step 2, the C5535 code will run to hand shake and wait for finishing the hand shake.
4. CCSV4 (version 4.2.4.00033) launches target configuration (which uses an empty Gel file based on Shawn’s great suggestion).
5. CCSV4 connects C5535 target board.  This operation will halt C5535 code; show the PC and C5535 register contents.
6. Do “CCSV4 run” – let previous booted C5535 code to continue running.
7. Run previous halted BB code.

The desired 128 data has been transferred from target board C5535 side to BB side.  In fact my code repeats doing two way data transfer successfully (to simplify the description, I only mentioned one way and one time transmitting).

If you can help me to find out what has been done in “CCSV4 launching target configuration + connecting target”, probably my boot problem will be solved.

Thanks!

Jun

Hello Jun,

I'm glad to see your code is making progress and up and running. If possible, could you tell me what code changes you did which brought you this far? 

Do you think it would have been possible that your BB code was sending a handshake before the DSP was ready? This may be why nothing seems like it was executing.

From your previous post, I understood:

1. It looks like you are restarting your system and then letting the BB to restart the DSP.
2. At this point the BB will be halted by you.
3. Meanwhile since you restarted the DSP it will reinitialize and then start polling for a handshake from the halted BB.
4. This is the point where you connect CCSv4 to the target board. What happens when you do not connect CCSv4? It it should be waiting to recieve a handshake anyways. Correct?
5. The next step you simply run the BB to send out a handshake and everything starts executing.

Am I to understand that you believe CCS is still required to have the DSP execute correctly?

Best Regards,

Nic

 -----------------------------------------------------------------------------------------------------------------------------------------------------------------

Please click verify if this answered your question. Thanks!

Nic:

My code has not been changed – it works well when run from CCSV4 – USB560M but failed when boot from flash.  Today’s finding just showing that my code only need two CCS operations (launch target – connect target, even without loading symbol, without real Gel functions) will be able to run correctly.  Therefore, I need you to help finding out “what has been done in “CCSV4 launching target configuration + connecting target”.  TI as a company to develop CCS definitely has the answer to this question.  Could you please forward this question to your CCS developer?

Thank you very much!

Jun

I think one item that may be overlooked is how different the timing and/or order of execution is when you get CCS involved, especially in your experiments when you pause the CPU side and then reset the dsp. Essentially you are creating a very long delay between the cpu reset and the initial I2S traffic generated from the CPU side in your experiment (a delay that will not be present when the code runs without intervention) and so I think Nic's question was whether the system works properly when you pause the CPU side and do a dsp reset and then start up the cpu side again.  I apologize in advance if you've already discussed or tried this but I am curious of the results of the following test, which are your steps from above with three steps omited as shown (omit steps 4 - 6.)

1. Write my test.bin file into C5535 target board Flash.
2. Run BB code to the beginning of handshake code, and halt there.
3. Use BB IO port to reset target board C5535 to boot the code from Flash.  Because of step 2, the C5535 code will run to hand shake and wait for finishing the hand shake.
4. CCSV4 (version 4.2.4.00033) launches target configuration (which uses an empty Gel file based on Shawn’s great suggestion).
5. CCSV4 connects C5535 target board.  This operation will halt C5535 code; show the PC and C5535 register contents.
6. Do “CCSV4 run” – let previous booted C5535 code to continue running.
7. Run previous halted BB code.

Shawn and Nic:

I always appreciate your providing me test ideas, check lists …  Your thought are very reasonable.  In fact, I considered these timing issues in early test stage.  So far our case and findings are:

1. Without CCS involved, boot from Flash always failed.

2. Using BB IO port to reset target board C5535 has several steps – BB set DSP rest pin low; turn on DSP power; wait 100 ms for DSP power got stabled; set DSP rest pin high.

3. In the very beginning of DSP code initialization is a long time delay.  Then do the registers and clock initialization.

Since with your help so many things have been checked, I also thing about some kind hardware issue caused this boot failure.  Though using DSP direct handle data to I2S without DMA, the code can boot from flash and run well.    In the mean time, please help me find out what has been done in “CCSV4 launching target configuration + connecting target”. 

Thanks!

Jun

Hi Jun,

Jun Cao said:

 In the mean time, please help me find out what has been done in “CCSV4 launching target configuration + connecting target”. 

When you launch a target configuration, CCS will:

-read the target configuration file (*.ccxml) for which a launch is started for

-configure the debugger for the target defined in the file

-launch the debugger

-call the GEL' StartUp()' call-back function. If the 'StartUp()' function is defined, it will execute any steps defined in the function. The 'StartUp()' function is usually defined in the GEL startup file (if one exists).

When you connect to the target, the debugger will attempt to halt the target (if it is running), and then establish communication between the emulator and the target. It will also call the GEL 'OnTargetConnect()'  call-back function. If the 'OnTargetConnect()' function is defined, it will execute any steps defined in the function. The 'OnTargetConnect()' function is usually defined in the GEL startup file (if one exists).

Note that there can be variations with the above steps. It all depends on what the debugger options are set for. For example, CCS will auto-run to 'main' after a target connect by default. This can be disabled or configured to run to different label than 'main'. If your device support real-time mode, it can be configured so that the target is not halted when connecting. When launching the debugger via a lunch configuration, it may be configured to auto-load a specific program after the target connect. The debugger may be configured to reset the target before a program load. As you can see, the environment is very configurable. Check your debugger options and launch configuration to see which options are set.

Slides 27-34 of the CCSv4 Tips and Tricks covers where you can access some of these options: http://processors.wiki.ti.com/images/0/09/CCSv4_Tips_%26_Tricks.pdf

Thanks

ki

Hi Ki,

Thank you so much for your answers and very useful Slides.  

By this Friday I have to first evaluate our new board hardware and my corresponding device drivers. I will back to work on this DMA issue next week. Based on these slides, I will first check my existing debugger options and think about CCS effect to execution of boot code and DSP initial state or environment.  Your help indeed give me a lot to think.

Thanks!

Jun

The RBL idles the MPORT domain, so the application needs to pull MPORT out of idle by clearing the MPORTI bit in the ICR register then issuing the IDLE command.  The code snippet below should be the first sequence in main().

regards -emil

#define SYS_ICR        *(volatile ioport Uint16*)(0x0001)