• State Resolved
  • Locked Locked
  • Replies 54 replies
  • Answers 1 answer
  • Subscribers 105 subscribers
  • Views 8000 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.

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

Jun Cao
Intellectual 310 points

I use CCSV5.3 (with latest update) to debug C5535 DSP based application through Blackhark USB560M JTAG Emulator. 

I first tried a short application project, V2EP0Test.  I was able to build V2EP0Test.out file; load V2EP0Test.out to the target board (my application board); run the code and get the correct results.  Then I generate the V2EP0Test.bin file from V2EP0Test.out as below run record.

C:\G2V2_workspace\V2EP0Test\Debug>"C:/TI_CCSV5/ccsv5/tools/compiler/c5500_4.4.1/bin/hex55.exe" V2EP0Test_Debug_bin.cmd

Translating to Binary format...

   ".\V2EP0Test.out"   ==> .const       (BOOT LOAD)

   ".\V2EP0Test.out"   ==> .cinit       (BOOT LOAD)

   ".\V2EP0Test.out"   ==> .switch      (BOOT LOAD)

   ".\V2EP0Test.out"   ==> .text        (BOOT LOAD)

   ".\V2EP0Test.out"   ==> vectors      (BOOT LOAD)

 

C:\G2V2_workspace\V2EP0Test\Debug>type V2EP0Test_Debug_bin.cmd

/* Convert a .out file to a binary *.bin file */

 

-boot       /* Make a boot table */

 

-v5505          /* Boot format */

 

-serial8    /* A byte-wide serial flash will be used */

 

-b                      /* for binary */

 

-map .\V2EP0Test.mxp   /* Map file generated by hex55 */

 

-o .\V2EP0Test.bin      /* Output file name for the resulting boot table */

 

.\V2EP0Test.out                 /* Input file */

 

However after loaded the V2EP0Test.bin to the flash memory, boot C5535 (load V2EP0Test.bin and run) could not give me the correct results.

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.

 

I am looking for experts’ help:

1. Is there a way to trace this bin file boot problem?

2. Just give me your guess – what can cause this problem

Thanks!

Jun Cao

  • 0 in reply to Emil2318
    Intellectual 310 points

    Emil:

    Thank you for this magic solution.  I fully tested it in two different DMA cases (DMA – I2S communication and ADC –I2S –DMA data collection).  With this solution the DMA related application can successfully boot from flash.

    Many thanks should also give to Shawn, Nic and Ki they provided a way to trace bin file boot problem and guiding me done a lot experiments.  As Emil said, our post gave him a hint: the “CCSV4 launching target configuration + connecting target” did some thing to fix the DMA code boot problem.

    Jun 

  • 0 in reply to Emil2318
    Expert 1525 points

    Emil,

    That was a great piece of information you provided regarding the ICR.  It prompted me to double check some of my apps that use the DMA and here is an interesting observation: I have an app that boots properly and uses the DMA, yet I don't have any code that tweeks the ICR bits.  In fact if I launch the code via the bootloader and then connect to the target with the emulator (with an "Empty" GEL file, so as not to issue any CPU Resets or run any scripts), the value of the ICR and ISTR are both 0x028E.

    The value of 0x028E would indicate that everything is enabled Except the FFT hw accelerator and the MPORT, yet somehow my code is working. Any thoughts?

    I am using the 5535 ezdsp and booting from the SDCARD.

    PS. I can post this on a new thread if you'd prefer. 

    PS PS I noticed that the DMA_init( ) function in the 3.01 CSL does not initialize or do anything with the MPORT bit of the ICR.  That functionality should probably be added to the CSL.

    thanks

    -Shawn

  • 0 in reply to Shawn Steenhagen
    Intellectual 310 points

    Shawn:

     Last week Emil pointed to me

    ..\ccsv4\emulation\boards\ezdsp5535_v1\boot_post_SDcard\boot_post\main.c

    which has below code.

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

    void main( void )

    {

        /* Initialize board */

        systemInit();

    ….

    void systemInit(void)

    {

        Uint16 i;

        PLL_Obj pllObj;

        CSL_Status status;

        PLL_Handle hPll;

        PLL_Config *pConfigInfo;

        PLL_Config pllCfg_v2_100MHz    = {0x8BE8, 0x8000, 0x0806, 0x0000};

       

        /* Config Idle control */

        SYS_ICR = 0xFF2E;

        asm(" IDLE");

    ….

    I wonder when your DMA involved application code booting from the SDCARD, you might already run above code to bring DMA out of idle state.

    Regards,

    Jun

  • 0 in reply to Jun Cao
    Expert 1525 points

    Jun,

    That is the mystery.  Our code does nothing to the SYS_ICR, it is essentially left alone and has the value of 0x028e, which would indicate that the MPORT is not enabled, yet somehow our DMA based code is working...

    In reading the CPU guide, it talks about situation where the IDLE request for the MPORT might be ignored.  Maybe that is the case when booting from the SDCard.

    -S