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.

C6657 SPI boot problem

Expert 2875 points

Hi Rahul,

I have been discusing this issue on other thread.  You ask for a new post for easy track.  Here is this new post.

The RBL only reads the 40 bytes (high lighted) then stops.  What might be the problem?  I am attaching the scope capture for your inspection.  That includes analog display for Chip Select.

Thank you.

Regards,

Steve

  • Steve,

     The chip select seems to go high after the last transaction hence there is no transfer on the SPI port. This could occur if the device gets configured by the RBL such that the SPI clock is not configured accurately or if the device is not configured so that the boot image can be loaded onto it memories

    Observation from the MAP file you provided :

    DDR configuration needs to be placed at 0x008ffd20 not at 0x00873500 as specified in you map file.The size of the DDR configuration table is 0x180 not 0x100. This is different for C6678 and C6657 devices so you may have gotten this from an example created for a different device. This is most likely the reason why the application is not booting.

    All sections of your application are in the DDR memory, but since the RBL doesn`t find the DDR configuration where it expects DDR3 is not configured and hence it is not able to proceed to transfer the boot image.

    Here is an example of C6657 SPI NOR boot with DDR initialized. You can refer to the structure used and the memory location where the DDR configuration table needs to reside.

    0066.SPIboot_ddr.zip

    Please give this a try and let us know if this resolved your issue.

    Regards,

    Rahul

  • Rahul,

    Without completely understand your message above, I just load spirom_le.swap.bin to FLASH.

    RBL read 00 50 00 continuously without proceeding.  See attached scope capture.  Thanks..  Steve.

  • What is your boot switch settings while trying the example. It may be good to check the the DEVSTAT register to capture the value latched in. Look at the wiki page provided here for SPI boot switch settings. Use the settings specified by ROM SPI Boot. Also ensure that the boot switches are configured to no-boot when you write to the SPI flash.

    Regards,

    Rahul

  • Rahul,

    Thanks for the reply.  We changed boot switch to 24 bit address and RBL went further.  It read first 80 bytes.  Then reading address 0x510400 got value 0x00000000, and continue reading it indefinitely.

    Now DEVSTAT register value is 0x0000140D.

    Our hardware boot switches are controled by FPGA and cannot altered easily.  Why do we need to have boot switches to no-boot to write SPI FLASH.  We use M25P80 1MB Flash.  We can write to FLASH without problem regardless of boot switch.

    Thank you.

    Steve

  • Steve,

    The no boot option is only a precaution so that there is no RBL generated device initialization which may cause an issue with the SPI writer process. Have you check the DDR location where the application needs to load to see if anything got loaded. Can you connect to device and see if the DDR got initialized correctly and you are able to write values through the memory browser.

    What other difference in hardware do you have from the EVM? What is the OSCIN value have you confirmed the values of PLL multipliers and dividers on the device by running a GEL file with the same settings?
     

    Regards,

    Rahul

  • Rahul,

    When RBL boot from your bin file, the core is all messed up, such as clock is divided by 1000, loading file crashes the code.  I have to short FLASH chip to boot.  Then attached emulator to the target and run.  DDR location is not loaded.

    OSCIN = 100MHz, PLL settings are the same as GEL file's from CCSv5.

    Do you have a good working bin file for me?   We can try no DDR first.

    Thank you.

    Regards,

    Steve

  • Rahul,

    I am getting a bit further by hand modify the the 0x51 to 0x00.

    Now the RBL repeatedly reading at address 0x400 for 4 bytes, then 0x404 for a lot of bytes.

    Thank you.

    Regards,

    Steve

  • Oh, RBL stops reading after about 2 minutes.  What might be the problem?

  • Steve,

    Did you correct the address of the DDR3 configuration table in the application. Please post the map file from the modified application so that I can confirm. Also did you check to see if the DDR3 initialization has completed correctly. Please also provide responses to the hardware difference ? Did you give this a try on the EVM and then on your hardware?

    Regards,

    Rahul

  • Rahul,

    I changed DDR3 address in simple.cmd file.  simple.map is attached as simple.map.txt.  When C6657 boot with the file in FLASH, either emulator cannot connect to target or cannot load code to run.  So I don't know how to check if the DDR3 initialized correctly.  Our hardware is very similar to the EVM, except we use M25P80 FLASH (SPI mode = 1).

    My EVM is down now and need to be fixed.

    Thank you.

    Regards,

    Steve

    4011.simple.map.txt
    ******************************************************************************
                   TMS320C6x Linker PC v7.4.2                      
    ******************************************************************************
    >> Linked Thu Feb 20 10:16:03 2014
    
    OUTPUT FILE NAME:   <simple.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 80010000
    
    
    MEMORY CONFIGURATION
    
             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
    PAGE 0:
      DDRCFG                008ffd20   00000180  00000068  00000118  RWIX
    
    PAGE 1:
      TEXT                  80010000   00000040  00000040  00000000  RWIX
      DATA                  80010100   00000004  00000004  00000000  RWIX
      BYTE1                 80010201   00000001  00000001  00000000  RWIX
      BYTE2                 80010210   00000002  00000002  00000000  RWIX
    
    
    SECTION ALLOCATION MAP
    
     output                                  attributes/
    section   page    origin      length       input sections
    --------  ----  ----------  ----------   ----------------
    .ddrCfg    0    008ffd20    00000068     
                      008ffd20    00000068     ddrcfg.obj (.ddrCfg)
    
    .text      1    80010000    00000040     
                      80010000    00000040     simple.obj (.text)
    
    .data      1    80010100    00000004     
                      80010100    00000004     simple.obj (.data)
    
    .byte1     1    80010201    00000001     
                      80010201    00000001     simple.obj (.byte1)
    
    .byte2     1    80010210    00000002     
                      80010210    00000002     simple.obj (.byte2)
    
    
    GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name 
    
    address    name
    --------   ----
    00000000   $bss
    80010100   .data
    80010000   .text
    008ffd7c   EccAddrRange1
    008ffd80   EccAddrRange2
    008ffd78   EccCtrl
    008ffd20   EnableBitmap
    008ffd48   IODFT_TLGC
    008ffd58   IrqEnable
    008ffd70   MtrIdClassMap1
    008ffd74   MtrIdClassMap2
    008ffd40   NVMTiming
    008ffd4c   PerfCtrCfg
    008ffd50   PerfCtrSel
    008ffd64   PhyCtrl1
    008ffd68   PhyCtrl2
    008ffd24   PllCfg
    008ffd44   PowerMgmt
    008ffd6c   PriClassMap
    008ffd54   RdIdleCtl
    008ffd84   RwExcThresh
    008ffd28   SDRAMConfig
    008ffd2c   SDRAMConfig2
    008ffd30   SDRAMRefreshCtl
    008ffd34   SDRAMTiming1
    008ffd38   SDRAMTiming2
    008ffd3c   SDRAMTiming3
    008ffd60   TempAlertCfg
    008ffd5c   ZqCfg
    ffffffff   ___TI_pprof_out_hndl
    ffffffff   ___TI_prof_data_size
    ffffffff   ___TI_prof_data_start
    ffffffff   ___binit__
    ffffffff   ___c_args__
    ffffffff   ___cinit__
    80010100   ___data__
    80010104   ___edata__
    80010040   ___etext__
    ffffffff   ___pinit__
    80010000   ___text__
    80010000   _c_int00
    ffffffff   binit
    80010201   byte1
    80010210   byte2
    ffffffff   cinit
    80010104   edata
    80010040   etext
    ffffffff   pinit
    80010100   someData
    
    
    GLOBAL SYMBOLS: SORTED BY Symbol Address 
    
    address    name
    --------   ----
    00000000   $bss
    008ffd20   EnableBitmap
    008ffd24   PllCfg
    008ffd28   SDRAMConfig
    008ffd2c   SDRAMConfig2
    008ffd30   SDRAMRefreshCtl
    008ffd34   SDRAMTiming1
    008ffd38   SDRAMTiming2
    008ffd3c   SDRAMTiming3
    008ffd40   NVMTiming
    008ffd44   PowerMgmt
    008ffd48   IODFT_TLGC
    008ffd4c   PerfCtrCfg
    008ffd50   PerfCtrSel
    008ffd54   RdIdleCtl
    008ffd58   IrqEnable
    008ffd5c   ZqCfg
    008ffd60   TempAlertCfg
    008ffd64   PhyCtrl1
    008ffd68   PhyCtrl2
    008ffd6c   PriClassMap
    008ffd70   MtrIdClassMap1
    008ffd74   MtrIdClassMap2
    008ffd78   EccCtrl
    008ffd7c   EccAddrRange1
    008ffd80   EccAddrRange2
    008ffd84   RwExcThresh
    80010000   .text
    80010000   ___text__
    80010000   _c_int00
    80010040   ___etext__
    80010040   etext
    80010100   .data
    80010100   ___data__
    80010100   someData
    80010104   ___edata__
    80010104   edata
    80010201   byte1
    80010210   byte2
    ffffffff   ___TI_pprof_out_hndl
    ffffffff   ___TI_prof_data_size
    ffffffff   ___TI_prof_data_start
    ffffffff   ___binit__
    ffffffff   ___c_args__
    ffffffff   ___cinit__
    ffffffff   ___pinit__
    ffffffff   binit
    ffffffff   cinit
    ffffffff   pinit
    
    [49 symbols]
    

     

  • Hi Steve,

    Thanks for sending in the map file. Though the location of the DDR3 configuration table now appears to be correct, the size of the struct is much smaller than what I would have expected. It should be around 0x178 as compared to 0x68

    Yes, you are correct the 0x51 in the binary needs to be changed to 0x00 as you can see from the spirom_le_swap.dat file. That is the file that we used to program the SPI flash on the EVM.  Is it possible for you to try this on the EVM first before trying it on your board? If it works on the EVM but doesn`t work on your board, we would like to check if there is any difference in the DDR3 part used on your board.


    Regards,

    Rahul

  • Hi Rahul,

    Thanks for the reply.  BTY, we have a Webex conference call today at 2PM Pacific time.

    My C6657L EVM does not work now due to repeated hardware modification.

    Now I am using the SPIboot_ddr code and here are the results.   The boot is not consistent, some time just read first block.  Sometimes read all, first block plus three reads from 0x400, 0x800 and 0xC00.  With that boot, I can see internal memory data loaded, but not DDR data.  Hence the code crashes and resulting all kinds of problem, such emulator can not connect to target, or cannot load code.

    I am attaching that map for your inspection.  That map has DDR_CFG size 0x178.

    5460.spiboot.map.txt
    ******************************************************************************
                   TMS320C6x Linker PC v7.4.2                      
    ******************************************************************************
    >> Linked Thu Feb 20 15:38:16 2014
    
    OUTPUT FILE NAME:   <spiboot.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 80000680
    
    
    MEMORY CONFIGURATION
    
             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      DDR_CFG               008ffd20   00000180  00000178  00000008  RWIX
      L2MAGIC               008ffffc   00000004  00000000  00000004  RWIX
      DDR                   80000000   00002000  00000d0c  000012f4  RWIX
    
    
    SEGMENT ALLOCATION MAP
    
    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    008ffd20    008ffd20    00000178   00000178    r--
      008ffd20    008ffd20    00000178   00000178    r-- .emif4Cfg
    80000000    80000000    000008e0   000008e0    r-x
      80000000    80000000    000008e0   000008e0    r-x .text
    800008e0    800008e0    00000400   00000000    rw-
      800008e0    800008e0    00000400   00000000    rw- .stack
    80000ce0    80000ce0    0000000c   0000000c    rw-
      80000ce0    80000ce0    0000000c   0000000c    rw- .fardata
    80000cec    80000cec    00000020   00000020    r--
      80000cec    80000cec    00000020   00000020    r-- .cinit
    
    
    SECTION ALLOCATION MAP
    
     output                                  attributes/
    section   page    origin      length       input sections
    --------  ----  ----------  ----------   ----------------
    .emif4Cfg 
    *          0    008ffd20    00000178     
                      008ffd20    00000178     spiboot.obj (.emif4Cfg)
    
    .text      0    80000000    000008e0     
                      80000000    00000180     rts6600_elf.lib : copy_decompress_rle.obj (.text:__TI_decompress_rle_core)
                      80000180    00000100                     : autoinit.obj (.text:_auto_init_elf)
                      80000280    00000100                     : cpy_tbl.obj (.text:copy_in)
                      80000380    000000e0                     : copy_zero_init.obj (.text:decompress:ZI:__TI_zero_init)
                      80000460    000000c0                     : exit.obj (.text:exit)
                      80000520    000000c0                     : tls.obj (.text:tls:init:__TI_tls_init)
                      800005e0    000000a0                     : memcpy64.obj (.text:memcpy)
                      80000680    00000080                     : boot.obj (.text:_c_int00)
                      80000700    00000060                     : cpp_init.obj (.text:__TI_cpp_init)
                      80000760    00000040                     : args_main.obj (.text:_args_main)
                      800007a0    00000040                     : tls.obj (.text:tls:get_addr:__c6xabi_get_addr)
                      800007e0    00000020                     : exit.obj (.text:abort)
                      80000800    00000020                     : copy_decompress_none.obj (.text:decompress:none:__TI_decompress_none)
                      80000820    00000020                     : copy_decompress_rle.obj (.text:decompress:rle24:__TI_decompress_rle24)
                      80000840    00000020                     : copy_decompress_rle.obj (.text:decompress:rle:__TI_decompress_rle)
                      80000860    00000020     spiboot.obj (.text)
                      80000880    00000020     rts6600_elf.lib : tls.obj (.text:tls:block_size:__TI_tls_block_size)
                      800008a0    00000020                     : tls_get_tp.obj (.text:tls:get_tp)
                      800008c0    00000020                     : tls.obj (.text:tls:main_base:__TI_tls_main_thread_base)
    
    .stack     0    800008e0    00000400     UNINITIALIZED
                      800008e0    00000008     rts6600_elf.lib : boot.obj (.stack)
                      800008e8    000003f8     --HOLE--
    
    .fardata   0    80000ce0    0000000c     
                      80000ce0    0000000c     rts6600_elf.lib : exit.obj (.fardata)
    
    .cinit     0    80000cec    00000020     
                      80000cec    0000000d     (.cinit..fardata.load) [load image, compression = rle]
                      80000cf9    00000003     --HOLE-- [fill = 0]
                      80000cfc    00000008     (__TI_handler_table)
                      80000d04    00000008     (__TI_cinit_table)
    
    
    LINKER GENERATED COPY TABLES
    
    __TI_cinit_table @ 80000d04 records: 1, size/record: 8, table size: 8
    	.fardata: load addr=80000cec, load size=0000000d bytes, run addr=80000ce0, run size=0000000c bytes, compression=rle
    
    
    LINKER GENERATED HANDLER TABLE
    
    __TI_handler_table @ 80000cfc records: 2, size/record: 4, table size: 8
    	index: 0, handler: __TI_decompress_rle24
    	index: 1, handler: __TI_decompress_none
    
    
    GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name 
    
    address    name
    --------   ----
    800007e0   C$$EXIT
    80000d04   __TI_CINIT_Base
    80000d0c   __TI_CINIT_Limit
    80000cfc   __TI_Handler_Table_Base
    80000d04   __TI_Handler_Table_Limit
    UNDEFED    __TI_INITARRAY_Base
    UNDEFED    __TI_INITARRAY_Limit
    80000ce0   __TI_STACK_END
    00000400   __TI_STACK_SIZE
    00000000   __TI_STATIC_BASE
    UNDEFED    __TI_TLS_BLOCK_SIZE
    UNDEFED    __TI_TLS_INIT_Base
    UNDEFED    __TI_TLS_INIT_Limit
    UNDEFED    __TI_TLS_MAIN_THREAD_Base
    00000001   __TI_args_main
    80000700   __TI_cpp_init
    80000800   __TI_decompress_none
    80000840   __TI_decompress_rle
    80000820   __TI_decompress_rle24
    80000ce8   __TI_enable_exit_profile_output
    ffffffff   __TI_pprof_out_hndl
    ffffffff   __TI_prof_data_size
    ffffffff   __TI_prof_data_start
    80000880   __TI_tls_block_size
    80000520   __TI_tls_init
    800008c0   __TI_tls_main_thread_base
    80000380   __TI_zero_init
    ffffffff   __binit__
    800007a0   __c6xabi_get_addr
    800008a0   __c6xabi_get_tp
    ffffffff   __c_args__
    80000760   _args_main
    80000180   _auto_init_elf
    80000680   _c_int00
    80000ce0   _cleanup_ptr
    80000ce4   _dtors_ptr
    800008e0   _stack
    800007e0   abort
    ffffffff   binit
    80000280   copy_in
    008ffd20   emif4Cfg
    80000460   exit
    80000860   main
    800005e0   memcpy
    
    
    GLOBAL SYMBOLS: SORTED BY Symbol Address 
    
    address    name
    --------   ----
    00000000   __TI_STATIC_BASE
    00000001   __TI_args_main
    00000400   __TI_STACK_SIZE
    008ffd20   emif4Cfg
    80000180   _auto_init_elf
    80000280   copy_in
    80000380   __TI_zero_init
    80000460   exit
    80000520   __TI_tls_init
    800005e0   memcpy
    80000680   _c_int00
    80000700   __TI_cpp_init
    80000760   _args_main
    800007a0   __c6xabi_get_addr
    800007e0   C$$EXIT
    800007e0   abort
    80000800   __TI_decompress_none
    80000820   __TI_decompress_rle24
    80000840   __TI_decompress_rle
    80000860   main
    80000880   __TI_tls_block_size
    800008a0   __c6xabi_get_tp
    800008c0   __TI_tls_main_thread_base
    800008e0   _stack
    80000ce0   __TI_STACK_END
    80000ce0   _cleanup_ptr
    80000ce4   _dtors_ptr
    80000ce8   __TI_enable_exit_profile_output
    80000cfc   __TI_Handler_Table_Base
    80000d04   __TI_CINIT_Base
    80000d04   __TI_Handler_Table_Limit
    80000d0c   __TI_CINIT_Limit
    ffffffff   __TI_pprof_out_hndl
    ffffffff   __TI_prof_data_size
    ffffffff   __TI_prof_data_start
    ffffffff   __binit__
    ffffffff   __c_args__
    ffffffff   binit
    UNDEFED    __TI_INITARRAY_Base
    UNDEFED    __TI_INITARRAY_Limit
    UNDEFED    __TI_TLS_BLOCK_SIZE
    UNDEFED    __TI_TLS_INIT_Base
    UNDEFED    __TI_TLS_INIT_Limit
    UNDEFED    __TI_TLS_MAIN_THREAD_Base
    
    [44 symbols]
    

    Thank you.

    Regards,

    Steve

  • Hi Rahul,

    I changed spiboot.cmd file to put everything in internal memory.  I can see code loaded correctly.  But the boot still crashes, PC=0x117BFE7C.  So I think we have two problems to solve:  1) DDR3 not configure correctly; and 2)  execution doesn't start at _c_int00.

    Thank you.

    Regards,

    Steve

  • Does your rmd file have this flag:   -e  _c_int00    added to it? what part of internal memory have you placed your code? Try to place the entire application in the MSMC region instead of L2 and let me know if you still see this issue.

    Regards,

    Rahul

  • I do have -e _c_int00 in my rmd file.  I change spiboot.cmd file to allocation all into MCSC.  Please see attached map and rmd files.

    After the boot, I stop the processor and file PC is in a loop.   see the following.  Also, while connected to target, I did a system reset and load the code to run.  But it goes to that PC and running in the loop again.  What is the problem?

    0285.spiboot.map.txt
    ******************************************************************************
                   TMS320C6x Linker PC v7.4.2                      
    ******************************************************************************
    >> Linked Fri Feb 21 11:17:08 2014
    
    OUTPUT FILE NAME:   <spiboot.out>
    ENTRY POINT SYMBOL: "_c_int00"  address: 0c0008a0
    
    
    MEMORY CONFIGURATION
    
             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      DDR_CFG               0c000000   00000180  00000178  00000008  RWIX
      L2MAGIC               0c000200   00000004  00000000  00000004  RWIX
      DDR                   0c000210   00002000  00000d0c  000012f4  RWIX
    
    
    SEGMENT ALLOCATION MAP
    
    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    0c000000    0c000000    00000178   00000178    r--
      0c000000    0c000000    00000178   00000178    r-- .emif4Cfg
    0c000210    0c000210    0000000c   0000000c    rw-
      0c000210    0c000210    0000000c   0000000c    rw- .fardata
    0c000220    0c000220    000008e0   000008e0    r-x
      0c000220    0c000220    000008e0   000008e0    r-x .text
    0c000b00    0c000b00    00000400   00000000    rw-
      0c000b00    0c000b00    00000400   00000000    rw- .stack
    0c000f00    0c000f00    00000020   00000020    r--
      0c000f00    0c000f00    00000020   00000020    r-- .cinit
    
    
    SECTION ALLOCATION MAP
    
     output                                  attributes/
    section   page    origin      length       input sections
    --------  ----  ----------  ----------   ----------------
    .emif4Cfg 
    *          0    0c000000    00000178     
                      0c000000    00000178     spiboot.obj (.emif4Cfg)
    
    .fardata   0    0c000210    0000000c     
                      0c000210    0000000c     rts6600_elf.lib : exit.obj (.fardata)
    
    .text      0    0c000220    000008e0     
                      0c000220    00000180     rts6600_elf.lib : copy_decompress_rle.obj (.text:__TI_decompress_rle_core)
                      0c0003a0    00000100                     : autoinit.obj (.text:_auto_init_elf)
                      0c0004a0    00000100                     : cpy_tbl.obj (.text:copy_in)
                      0c0005a0    000000e0                     : copy_zero_init.obj (.text:decompress:ZI:__TI_zero_init)
                      0c000680    000000c0                     : exit.obj (.text:exit)
                      0c000740    000000c0                     : tls.obj (.text:tls:init:__TI_tls_init)
                      0c000800    000000a0                     : memcpy64.obj (.text:memcpy)
                      0c0008a0    00000080                     : boot.obj (.text:_c_int00)
                      0c000920    00000060                     : cpp_init.obj (.text:__TI_cpp_init)
                      0c000980    00000040                     : args_main.obj (.text:_args_main)
                      0c0009c0    00000040                     : tls.obj (.text:tls:get_addr:__c6xabi_get_addr)
                      0c000a00    00000020                     : exit.obj (.text:abort)
                      0c000a20    00000020                     : copy_decompress_none.obj (.text:decompress:none:__TI_decompress_none)
                      0c000a40    00000020                     : copy_decompress_rle.obj (.text:decompress:rle24:__TI_decompress_rle24)
                      0c000a60    00000020                     : copy_decompress_rle.obj (.text:decompress:rle:__TI_decompress_rle)
                      0c000a80    00000020     spiboot.obj (.text)
                      0c000aa0    00000020     rts6600_elf.lib : tls.obj (.text:tls:block_size:__TI_tls_block_size)
                      0c000ac0    00000020                     : tls_get_tp.obj (.text:tls:get_tp)
                      0c000ae0    00000020                     : tls.obj (.text:tls:main_base:__TI_tls_main_thread_base)
    
    .stack     0    0c000b00    00000400     UNINITIALIZED
                      0c000b00    00000008     rts6600_elf.lib : boot.obj (.stack)
                      0c000b08    000003f8     --HOLE--
    
    .cinit     0    0c000f00    00000020     
                      0c000f00    0000000d     (.cinit..fardata.load) [load image, compression = rle]
                      0c000f0d    00000003     --HOLE-- [fill = 0]
                      0c000f10    00000008     (__TI_handler_table)
                      0c000f18    00000008     (__TI_cinit_table)
    
    
    LINKER GENERATED COPY TABLES
    
    __TI_cinit_table @ 0c000f18 records: 1, size/record: 8, table size: 8
    	.fardata: load addr=0c000f00, load size=0000000d bytes, run addr=0c000210, run size=0000000c bytes, compression=rle
    
    
    LINKER GENERATED HANDLER TABLE
    
    __TI_handler_table @ 0c000f10 records: 2, size/record: 4, table size: 8
    	index: 0, handler: __TI_decompress_rle24
    	index: 1, handler: __TI_decompress_none
    
    
    GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name 
    
    address    name
    --------   ----
    0c000a00   C$$EXIT
    0c000f18   __TI_CINIT_Base
    0c000f20   __TI_CINIT_Limit
    0c000f10   __TI_Handler_Table_Base
    0c000f18   __TI_Handler_Table_Limit
    UNDEFED    __TI_INITARRAY_Base
    UNDEFED    __TI_INITARRAY_Limit
    0c000f00   __TI_STACK_END
    00000400   __TI_STACK_SIZE
    00000000   __TI_STATIC_BASE
    UNDEFED    __TI_TLS_BLOCK_SIZE
    UNDEFED    __TI_TLS_INIT_Base
    UNDEFED    __TI_TLS_INIT_Limit
    UNDEFED    __TI_TLS_MAIN_THREAD_Base
    00000001   __TI_args_main
    0c000920   __TI_cpp_init
    0c000a20   __TI_decompress_none
    0c000a60   __TI_decompress_rle
    0c000a40   __TI_decompress_rle24
    0c000218   __TI_enable_exit_profile_output
    ffffffff   __TI_pprof_out_hndl
    ffffffff   __TI_prof_data_size
    ffffffff   __TI_prof_data_start
    0c000aa0   __TI_tls_block_size
    0c000740   __TI_tls_init
    0c000ae0   __TI_tls_main_thread_base
    0c0005a0   __TI_zero_init
    ffffffff   __binit__
    0c0009c0   __c6xabi_get_addr
    0c000ac0   __c6xabi_get_tp
    ffffffff   __c_args__
    0c000980   _args_main
    0c0003a0   _auto_init_elf
    0c0008a0   _c_int00
    0c000210   _cleanup_ptr
    0c000214   _dtors_ptr
    0c000b00   _stack
    0c000a00   abort
    ffffffff   binit
    0c0004a0   copy_in
    0c000000   emif4Cfg
    0c000680   exit
    0c000a80   main
    0c000800   memcpy
    
    
    GLOBAL SYMBOLS: SORTED BY Symbol Address 
    
    address    name
    --------   ----
    00000000   __TI_STATIC_BASE
    00000001   __TI_args_main
    00000400   __TI_STACK_SIZE
    0c000000   emif4Cfg
    0c000210   _cleanup_ptr
    0c000214   _dtors_ptr
    0c000218   __TI_enable_exit_profile_output
    0c0003a0   _auto_init_elf
    0c0004a0   copy_in
    0c0005a0   __TI_zero_init
    0c000680   exit
    0c000740   __TI_tls_init
    0c000800   memcpy
    0c0008a0   _c_int00
    0c000920   __TI_cpp_init
    0c000980   _args_main
    0c0009c0   __c6xabi_get_addr
    0c000a00   C$$EXIT
    0c000a00   abort
    0c000a20   __TI_decompress_none
    0c000a40   __TI_decompress_rle24
    0c000a60   __TI_decompress_rle
    0c000a80   main
    0c000aa0   __TI_tls_block_size
    0c000ac0   __c6xabi_get_tp
    0c000ae0   __TI_tls_main_thread_base
    0c000b00   _stack
    0c000f00   __TI_STACK_END
    0c000f10   __TI_Handler_Table_Base
    0c000f18   __TI_CINIT_Base
    0c000f18   __TI_Handler_Table_Limit
    0c000f20   __TI_CINIT_Limit
    ffffffff   __TI_pprof_out_hndl
    ffffffff   __TI_prof_data_size
    ffffffff   __TI_prof_data_start
    ffffffff   __binit__
    ffffffff   __c_args__
    ffffffff   binit
    UNDEFED    __TI_INITARRAY_Base
    UNDEFED    __TI_INITARRAY_Limit
    UNDEFED    __TI_TLS_BLOCK_SIZE
    UNDEFED    __TI_TLS_INIT_Base
    UNDEFED    __TI_TLS_INIT_Limit
    UNDEFED    __TI_TLS_MAIN_THREAD_Base
    
    [44 symbols]
    
    3757.spiboot.rmd.txt
    spiboot.out
    -a
    -boot
    -e _c_int00
    -order L
    
    ROMS
    {
       ROM1:  org = 0x0400, length = 0x1000000, memwidth = 32, romwidth = 32
              files = { spiboot.btbl }
              
    }          
              
              
              
      

  • Hi Steve,

    I spoke to the RBL author regarding configuration of the SPI mode parameter in the parameter table and here is what he had to inform us:

    "The mode value is placed directly in the SPI hardware register. The SPI document available at ti.com describes what each value does. It changes the clock polarity and data phasing. Note that the values that TI uses for mode may not match up with what flash vendors use for mode.  Is it possible to just try all four mode values? 

    One thing I thought of is that if you have a different mode value for the write vs the read you may still actually read data, but it may be shifted by one bit with one bit lost"

    Can you please try to vary your SPI mode values and see if any of the settings works for you. I am still doing a memory dump compare and will let you know if I find any differences.

    Regards,

    Rahul

  • Hi Rahul,

    Thanks for the message.  I tried all combinations, 0:doesn't work; 1: works; 2: works and 3 doesn't work for SPI modes.

    For mode 1 and 2, I verified that data and code loaded by RBL is correctly reside in memory.  So I think our problem is why RBL jumps to 0x117802FC, instead of _c_init00 at 0x0c000980.

    Regards,

    Steve

  • Steve,

    Can you post you .bin file that you are trying to boot. I want to see if the cinit00 value is the first value on the boot image after the parameter table has been read in.

    Regards,

    Rahul

  • Here it is.   The _c_int00 address, 0x0c000980 is at 0x000404.

    2766.app.bin.txt
    P2@ ��L	�x�� @{��(bGz�O3x0q�U���pL��3:,,!
    ��������F6G�6�$6�` G�� $6�0�a � P�Z 2�6�2$� ���3�*�Nn� �
    Y�������0$�"��$� Z0�cc����x�$6����$6��XA!$6�”��•�����T$6���D��X������H����'�H�H�� @�65�����G�4+$�P��6U���YB��Ѐ(��6uC��F�����B����f��=E,�A�WD�Fgnn�3![ �Y G��)���"�u#�XĜUÜ�Xd"4d5c�@XD6467��$6�`���w%���%w���X���(�@���*‡�+��(�k�h†j��h�b)��*�)*i�j�ij����F��
    	���hg���0:A!���8��YŔ��m�"0Rd0"f<,n� ln&@�jd`b��b+�X�a!� �0Rd�0"f��� Y+�\�X�<R���<3�b�z�R�`�w6��)�("����(`x� �@x�0a!��bd��$ ���)��d��h��dcF��nn�@A#����� Y��(�h�����e�	�%��G� b��ba!("� X��	������b("� X� �	�� ��!!���(`y�A��bd��$��c<3��R�`f0���V��[dm�/Z�#�F�F��I �!G��g�wD0Y����`C�c 6U!�����K��G��1���A!Ƥ�c 6t���X”��f���,�WEg=E�FZ�[$!Y��"�tO[$ �Y# U�(!�4/[$ @Y!�"4!�4��)�T��h�d��Z������z�
    X��u�!��) 0c!�h d�@<"�nFF�b��(�hd@�@:��b`�b��(�hd�0���b`�b`�u�<"���R�`��6���*�k�w�w�)*�F'w� 0�)k��h�irF�����,����`������YM�hg�m�"�$�� 8�&"d<,n`4jdð���x� b�ab��Y+�()����!¬$��6�8��wgw�wf�v��`��)��G��X��6��)�؂�V���
    %y����7�N�V��Z#�7� ���h�`c(�7� �Z��65��@C�oR����V7��*��7U �Ô7u����Ȕ7v�7�@��@�7t��b��*�j�	�*j�Z	�
    ��@(�hb��b�0(�hb��b�*jb�ab�X����6��(�i+<5�j��� (zx�(6�o����b-Jz0�!2(6���0b��c<3��R�`��������*�k���'�b�2e��X��X1��X��YvbN1��� ��sb�b�Sb����x � �`Y��d��X��������b���(��b� �cb(hb(h@�cb(h � ��

  • Thanks for sharing it appears the _C_int00 value appears to be correct at offset 0x404 in the boot image. One other thing that you may want to check is the value of memory location 0x008ffffc after the boot completes. This is the location of the boot magic address to which the RBL will jump after boot completes. Can you confirm that this matches with 0x0c000980?


    Regards,

    Rahul

  • Yes, value at 0x008ffffc is 0x0c000980, the _c_int00.

  • Without change anything, or some reason, value at 0x008ffffc is 0x008F8B80 now.

  • With many tries, value at 0x008ffffc has been 0x008F8B80, not _c_int00 any more.  Don't know why.

  • I cannot get my EVM to boot any more.  I did not even load code from SPI NOR FLASH to memory.   Do you have a known working app.bin for my TMDSEVM6657LS?

  • Hi Steve,

    You can revert back to the SPI ddr example that I gave you and change the memory sections to be placed in MSMC and give this a try. I am not sure why the location of the magic address changed in the different tries.
    I can create a boot image for your board that you can try out.

    Regards,

    Rahul

  • Hi Rahul,

    I did your suggestion and it didn't work on EVM and my prototype boards.

    Now no matter what I do, none of the two boards will boot.  Don't know what's wrong.  We are going backwards.

    Need another webex.

    Thank you.

    Regards,

    Steve

  • Hi Steve,

    It should work on the EVM without any changes as we have tested the image multiple times. I can ask Tiemen to setup another webex but I am not sure why things that were working on Friday seem to have broken down ...do you see the loading of the image happening correctly on the scope or has that also changed? Can you ensure that the you have followed all the steps mentioned in the ReadMe.txt that is included in the example that I shared with you.

    Regards,

    Rahul

    PS: Also ensure that you are manually changing the 0x51 to 0x00 at the ox1F offset in your boot image before loading the boot image.

  • Hi Rahul,

    I followed the ReadMe.txt and here is the contents of 0x8000000.

    I can see loading of SPI bus on my prototype board.  But cannot see that on EVM.

    I did make the change from 0x51 to 00.  I am very puzzled.  Can't wait for the webex.

    Regards,

    Steve

  • Hi Rahul,

    After more testing, the Content at 0-x008FFFFC is in consistent, most of the time is 0x008F8B80, some time is 0x0C000980 (correct _c_int00) and once was 0x00000980.

    All data and code are loaded correctly by my quick observation.  But never run to _c_int00, hence neither main().

    Do you have definitive document for SPI boot, include field definitions?

    Thank you.

    Regards,

    Steve

  • Hi Steve,

    I am not sure why your observations are inconsistent. Have you eliminated the possibility of any hardware issues causing this issue? As far the example is concerned, I have shared the examples with a couple of more developers and they were able to get it to work on their EVMs. Is the EVM that you are using hardware modified one or is it the same as what we used during the first webex.

    Have you also looked at the SPI registers to see if they are being configured correctly when the data is read. You can look at them after the boot has failed to see if they are being set correctly.

    Regards,

    Rahul

  • Hi Steve,

    I looked at the datasheet for the SPI flash device M25P80 and this is what is mentioned in the datasheet for the SPI flash.

    These devices can be driven  with its serial peripheral interface (SPI) running in either of the following two SPI modes:
    • CPOL=0, CPHA=0
    • CPOL=1, CPHA=1

    For these two modes, input data is latched in on the rising edge of serial clock (C), and output data is available from the falling edge of C.

    Here is the description of mode in the datasheet for BOOTMODE[12:11].

    2 = Data is output on the falling edge of SPICLK. Input data is latched on the rising edge

    This sounds to me as though you should be setting the boot switches to have the mode setting as 2 instead of 1.

    I am trying to confirm this internally with the hardware engineers but we may need to loop in hardware engineers to confirm there aren`t any board level issues before trying to resolve the booting.

    Regards,

    Rahul

  • Hi Steve,

    Can you read 0x80 bytes from the memory location 0x008fff00 after the boot and check if the boot parameter table that was loaded in memory matches the nysh.spi.map. ? If this matches it would confirm that the first stage of the boot is passing and the boot failure is probably result of some issue in the second stage. We would need to start looking at the system PLL programming to see if maybe you are trying to overdrive the chip. Is it possible that the PLL reference clock that you are using does not match the EVM. Can you check on this detail with the hardware engineers.


    Regards,

    Rahul

  • Hi Rahul,

    I am attaching the memory display of address 0x8FFF00 with app.bin file.  The data is kind correct except the mode (both 1 or 2 works), but the endianness is not matching.

    Thank you.

    Regards,

    Steve

  • Hi Rahul,

    I was trying to load some real code to boot EVM.  But romparse crashes.  Do you have a romparse which can handle large .out files?

    Thanks.

    Regards,

    Steve

  • Can you please specify the error message that you get with the romparse? The romparse is provided in source so based on the error message ,we can change the romparse utility. 

    Regards,

    Rahul

  • Hi Steve,

    Were you able to confirm with your hardware engineers that the reference clock on your custom board matches to the 100MHz CORE_CLK ? I am attaching a snapshot of the schematics for Gauss EVM.

    We suspect that your PLL settings may be overdriving the chip so we need to know the value of the reference clock on your board. As an experiment can you chnage the value at offset 0x08 in the boot image from 0x4020_0002 to 0000_0000 to not change the PLL, and change the device frequency set from offset 0x18 from 0x3e8 to 0x138 to have the boot ROM read the boot image at the same speed that it read the boot parameter table (which seems to be working).


    Regards,

    Rahul


  • Hi Rahul,

    Thanks for the reply.  There are quite a few issues here.  I am going to answer one by one.

    1)  The 80 bytes at address 0x008FFF00 is the same in EVM and my prototype board.  So I think it is correct.

    2)  My hardware engineers is in the process of checking PLL out.  I have forwarded your post to them, and will keep you posted on the result.

    3)  romparse utility crashed without post any message.

    Did you find why location 0x008FFFFC is not _c_int00 address?

    Thank you.

    Regards,

    Steve

  • Hi Rahul,

    We measured SYSCLKOUTs from EVM and our prototype board.  The output frequencies are the same.

    probe 1 is EVM and probe 2 is our board.

  • Hi Rahul,

    We have confirmed that our custom board has 100MHz clock matching EVM.  Also, our SYSCLKOUT matching EVM's too.  But both clock rates are about 266MHz, not 1GH/6 as we expected.  Do you know why?

    Thank you.

    Regards,

    Steve

     

  • Hi Steve,

    Since the parameter table is being read correctly, the theory that we are working on right now is that the device may be overdriven when the boot table is being read that is causing some timing issues causing incorrect read of the c_int00 value. As per the ROM author we may be overclocking the device based on the values in the parameter table both on the EVM as well as the custom board. You are trying to set the main PLL clock to 1000 Mhz but with the PLL divider and multiplier values we may be driving the main PLL to 1600 MHZ which is out of spec.

    Can you perform the experiment of zeroing out the PLL settings in the parameter table and also setting the core clock to 0x138 instead of 0x3e8 and check to see if you can boot successfully. As far as your scope shot is concerned, can please specify what SYSCLKOUT is shown on the scope, it appears to be frequency of 265Mhz so I am not sure this is the core clock or the reference clock

    Regards,

    Rahul

  • I think we posted at the same time so our replies crossed. Our calculations show that from the values confiured in the parameter table the main PLL will be configured to 1600Mhz instead of 1000Mhz so the what your configuring seems to be accurate 1600/6 =266 Mhz. So we will need to chnage the values in the parameter table to achieve the 1000Mhz settings.

    Instead of booting from SPI can you load and run the GEL script to configure the PLLs and let me know what you see on the scope. The GEL file sets the core to 1GHz so you should be able to see 166 Mhz on the SYSCLK out. We can then modify the parameter table to attain the 1GHZ instead of the 1.6GHZ that we are setting.

    Regards,

    Rahul

  • Hi Rahul,

    I set core_freq_mhz = 312 (0x138) loaded the code and boot.  The same results.  0x008FFFFC is still 0x008F8980.  Also  SYSCLKOUT is still abour 265MHz.

    SYSCLKOUT is core clock/ 6.  • SYSCLK7: 1/6-rate clock for slow peripherals and sources the SYSCLKOUT output pin.  EVM TP12.

    I guess that we have not found the problem yet!

    Thanks.

    Regards,

    Steve

     

     

  • Steve,

    • Did you also change the 4020_0002 to 0000_0000 at offset 0x08 in boot image when you tried the experiment?
    • Do you get the same reading of the SYSCLK_OUT core_clock/6 when you run the GEL file? <- Running the GEL file should give you the correct output clock.
    • The other recommendation would be to try to change the value of N_PINS to 2 instead of 4.

    Regards,

    Rahul

  • Rahul,

    1)  I changed 4020_0002 to 0000_0000 by setting  sw_pll_prediv = 0, sw_pll_mult = 0, sw_pll_postdiv = 0 and sw_pll_flags = 0 in nysh.spi.map.  Load code to flash and run.  My prototype board boots correctly to main().  SYSCLKOUT show 16.6MHz and 0x2310110 (PLLM) = 0.

    2) Load EVM6657L.gel, the SYSCLKOUT is still 266MHz. 0x2310110 (PLLM) = 0x0000001F.

    3)  I manually change 0x2310110 (PLLM) = 0x00000013.  The SYSCLKOUT is 166MHz.

    Could you send me a nysh.spi.map file will boot 1000MHz?

    Do you have a fix for romparse.exe with larger file?

    Thank you.  We are getting closer to solve our boot problem.

    Regards,

    Steve

  • Hi Steve,

    Changing the sw_pll_prediv = 0x01, sw_pll_mult= 0x14, sw_pll_postdiv =0x02 should help you boot the device at 1000Mhz. Before you try to boot make sure that thet 0x4020_0002 value changes to 0x4014_0102.

    After loading the GEL file did you run the PLL initialization on the device? The GEL should be setting up the main PLL to 1000Mhz so you should have seen the SYSCLK_OUT = 166 MHZ. Please confirm that you have initialized the PLL from the GEL before measuring the SYSCLKOUT.


    I don`t have an updated version of the romparse as I am currently using the version of romparse provided in MCSDK. I will try to take a look at this and see if I can modify this utility for you.

    Regards,

    Rahul

  • Hi Rahul,

    By change sw+pll_mult to 0x14, I boot the device to 1000MHz (SYSCLKOUT = 166MHz).  By changing sw_pll_prediv to 0x01 from 0x02 makes no difference.  The value is 0x4014_0002 for both cases.

    Just by loading evm6657l.gen does not alter SYSCLKOUT rate.  Initialize PLL after that does set core clock to 1000MHz.  Thank you.

    I am attaching our .out file for you to test romparse.exe.   After you fix romparse, please let me know.

    Thank you very much for the extended support.

    Regards,

    Steve

    6735.McBSP_EDMA3.out.txt

  • Hi Rahul,

    Did you receive my .out file?  Did you get a chance to test your new romparse.exe?

    I looked at romparse source and found that in romparse.h, line 76 #define MAX_DATA_LEN_32bit   32768.   This number might be too small.

    Thank you.

    Regards,

    Steve

  • Hi Steve,

    I did receive your .out file and was able to build a boot image without any error. What version of MCSDK are you using? I am currently using mcsdk 2.01.02.06 and this didn`t generate an error. Did you try to change the max data length and rebuild the utility to see if this resolved the issue?

    Regards,

    Rahul

  • Hi Rahul,

    I am using mcsdk 2.01.02.05.  But I checked mcsdk 2.01.02.06.  it is identical to the romparse which you sent through E2E in SPIboot_ddr.  It has the same #define MAX_DATA_LEN_32bit   32768.

    I did not to change the length.  Because I am not able to build romparse on Windows PC.

    If your romparse.exe works with my .out file, could you send it to me to try out?

    Thank you.

    Regards,

    Steve

  • This issue was resolved offline by rebuilding the romparse utility provided in MCSDK and the b2i2c utility to increse the maximum size of the data array tht these utilities could handle.

    Regards,

    Rahul