• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 1686 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320C6748: Why dose the RBL repeat reading the magic word (0x41504954) when spi flash master mode booting?

j-breeze
Mastermind 7560 points
Part Number: TMS320C6748
Hi Champs,

I'm facing a problem when SPI flash master mode booting. 
The problem is that the RBL repeats a retry of reading a magic word (0x41504954).
After POR, the RBL read the magic word, then read the rom image data and the Jump & Close Command (0x58535906). 
And then, the RBL read the magic word again instead of starting my SBL.

I tried to replace the flash device on my custom board, but the phenomenon didn't change.
I also tried to execute OMAP-L1x Debug Gel, but I could not get any error code as below. I guess the error code was cleared by the RBL because of the repeating.

  C674X_0: GEL Output: ---------------------------------------------
  C674X_0: GEL Output: |               BOOTROM Info                |
  C674X_0: GEL Output: ---------------------------------------------
  C674X_0: GEL Output: ROM ID: d800k008 
  C674X_0: GEL Output: Silicon Revision 2.1
  C674X_0: GEL Output: Boot pins: 12
  C674X_0: GEL Output: Boot Mode: SPI1 Flash
  C674X_0: GEL Output: 
  ROM Status Code: 0x00000000 
  Description:C674X_0: GEL Output: No error
  C674X_0: GEL Output: 
  Program Counter (PC) = 0x00712FB0
  C674X_0: GEL Output: 

I'm not sure why the RBL read the magic word again. 
I think that there are no problems with the C6748 SPI I/O pins and the board assembly because the RBL can read the AIS keywords.

Could you please give me your advice what the possible causes are? Is there any conditional expression in the RBL code to read the magic word again?

Regards,
j-breeze
  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru** 116020 points

    J Breeze,

    This is not an issue with the ROM bootloader based on the information that you have shared. When the Debug GEL file shows that he code has jumped into RAM memory (0x00712FB0) and the ROM boot detected no error which means that user level code has started executing. Can you export the AIS config that you are using to generate the boot image for analysis.

    Can you indicate if the customer is loading a secondary bootloader or an application directly. If you have the map file for the secondary bootloader or the application, can check what function/code is located at location 0x00712FB0 . Also indicate if the application is BIOS application and if it meets the entry point alignment requirement specified here:
    processors.wiki.ti.com/.../Boot_Images_for_OMAP-L138

    Considering, user level code is executing a good way to debug this would be to load symbols for the .out that you are booting on the DSP after the boot fails. Do not use GEL file when connecting to the DSP else the system state will be changed.

    Regards,
    Rahul

  • 0 in reply to Rahul Prabhu
    Mastermind 7560 points

    Hi Rahul,

    I think there seems to be some misunderstanding about the memory address which the Debug GEL showed.
    The address 0x00712FB0 shows DSP L2 ROM area, not RAM memory. It means the RBL is running, not jumped to my SBL.

    I'd appreciate it if you can check it again

    Regards,
    j-breeze

  • 0 in reply to j-breeze
    Mastermind 7560 points

    Hi,

    I would appreciate it if you could reply by 10 a.m. on Monday, our time. Because I have to report the status of this issue to my boss.

    Regards,
    j-breeze

  • 0 in reply to j-breeze
    TI__Guru** 116020 points
    J-Breeze,

    My mistake. I misinterpreted your debug GEL file dump. I confirm that the code is executing in the DSP L2 ROM region but it is executing a BNOP instructions in a region that it should not be in for the C6748 device.

    Can you please export the AISGEN .cfg and share for our reference. Do you have scope shots of the SPI interaction when the ROM boot starts reading from SPI flash to share. Is this issue being seen on one board or multiple boards. Are you sure that there is no power sequencing issue. If the part is being reset after the first time the magic word is read from flash, can explain why it is re-reading the magic word. What SPI flash part is being used in the design, have you confirmed it uses read command (0x3) compatible with ROM. was the board previously booting and is this a new image that is being tried or is this the first time booting is being tested on the board. is the flash connected to SPI0 or SPI1 CS. Is it connected in 4 pin or 3 pin mode. Have you run any diagnostics on the platform to check out the DSP to SPI flash read/write is working as expected and is only an issue during power on.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Mastermind 7560 points

    Hi Rahul,

    Thank you for your support.

    First, the instruction at location 0x00712FB0 I confirmed is "B.S2  B0", not BNOP. The below is the CCS Disassembly window.
    And, I'd like to ask you about the RBL code. Is there any conditional expression in the RBL code that read the magic word again? 
    Could you please check the RBL code again?

    I will answer your questions in my another post.

     

    Regards,
    j-breeze 

  • 0 in reply to j-breeze
    Mastermind 7560 points
    Hi Rahul,

    I'm sorry for my late reply. I'd like to answer your questions one by one.

    //
    //  AISgen configuration file (*.cfg)
    //

    Could you please let me know how to share the file with you? Because I don't want to disclose it here.

    //
    //  Scope Shots of the SPI Interaction when Booting
    //

    I'd like to share the command sequence below, instead of the scope shots.
     
    After POR:

      S Read Data 0x41504954 from Address     0x000000  // Magic Word 
      - Read Data 0x5853590D from Address 0x000004  // Function Execute Command 
      - Read Data 0x00030006 from Address 0x000008  // PLL and Clock Configuration  
      - Read Data 0x001E0100 from Address 0x00000C  // Arg1  
      -      Data 0x00000207 on MISO                // Arg2  
      -      Data 0x00030000 on MISO                // Arg3  
      - Read Data 0x5853590D from Address 0x000018  // Function Execute Command   
      - Read Data 0x00080003 from Address 0x00001C  // mDDR/DDR2 Controller Configuration  
      - Read Data 0x18010002 from Address 0x000020  // Arg1  
      -      Data 0x00000003 on MISO                // Arg2  
      -      Data 0x000000C5 on MISO                // Arg3  
      -      Data 0x0013C822 on MISO                // Arg4  
      -      Data 0x264A3209 on MISO                // Arg5 
      -      Data 0x3C14C722 on MISO                // Arg6 
      -      Data 0xC0000492 on MISO                // Arg7 
      -      Data 0x00000000 on MISO                // Arg8 
      - Read Data 0x58535901 from Address 0x000040  // Section Load Command  
      - Read Data 0xC0CB7B10 from Address 0x000044  // Address 
      -      Data 0x00000010 on MISO                // Size 
      - Read Data 0x03020000 from Address 0x00004C  // Section Contents
      -      Data 0x03020103 on MISO                // Section Contents  
      -      Data 0x03030303 on MISO                // Section Contents 
      -      Data 0x01030202 on MISO                // Section Contents 
      - Read Data 0x58535901 from Address 0x00005C  // Section Load Command  
      - Read Data 0xC0CB7B20 from Address 0x000060  // Address
      -      Data 0x0008B800 on MISO                // Size 
      - Read Data 0xA1EF0626 from Address 0x000068  // Section Contents

             (Section Contents on MISO)

      - Read Data 0x58535901 from Address 0x08B868  // Section Load Command
      - Read Data 0xC0D43320 from Address 0x08B86C  // Address
      -      Data 0x0001C734 on MISO                // Size 
      - Read Data 0x30013000 from Address 0x08B874  // Section Contents 

             (Section Contents on MISO)

      - Read Data 0x58535901 from Address 0x0A7FA8  // Section Load Command
      - Read Data 0xC0D5FA58 from Address 0x0A7FAC  // Address
      -      Data 0x000041CC on MISO                // Size 
      - Read Data 0x00000020 from Address 0x0A7FB4  // Section Contents 

             (Section Contents on MISO)

      - Read Data 0x58535901 from Address 0x0AC180  // Section Load Command
      - Read Data 0xC0D64C28 from Address 0x0AC184  // Address
      -      Data 0x00000504 on MISO                // Size 
      - Read Data 0xC0CF3AE8 from Address 0x0AC18C  // Section Contents 

             (Section Contents on MISO)

      - Read Data 0x58535901 from Address 0x0AC690  // Section Load Command
      - Read Data 0xC0D65800 from Address 0x0AC694  // Address
      -      Data 0x00000200 on MISO                // Size 
      - Read Data 0x00000000 from Address 0x0AC69C  // Section Contents 

             (Section Contents on MISO)

      - Read Data 0x58535906 from Address 0x0AC89C  // Jump & Close Command
      E Read Data 0xC0D3D080 from Address 0x0AC8A0  // Address (Entry Point of My SBL)
     
             !!! Don't Jump to My SBL !!!
     
      S Read Data 0x41504954 from Address 0x000000  // Magic Word 
      - Read Data 0x5853590D from Address 0x000004  // Function Execute Command 
      - Read Data 0x00030006 from Address 0x000008  // PLL and Clock Configuration  

             .
             .
             .

      - Read Data 0x58535906 from Address 0x0AC89C  // Jump & Close Command
      E Read Data 0xC0D3D080 from Address 0x0AC8A0  // Address (Entry Point of My SBL)

             !!! Repeat Steps S TO E !!!

    //
    //      Frequency of Occurrence
    //

    This issue is being seen on one board so far, and it happens every booting.
    I tried to replace the flash device, but the issue still occured.
    I've never seen a successful boot on the board, but on another board I saw a normal boot.

    //
    //  Power Sequencing Issue 
    //
     
    I'm sure that there is no power sequencing issue.

    //
    //  Reset after the First Time the Magic Word is Read
    //

    ​I'm sure that there is no reset assertion after the ROM boot starts

    //
    //  SPI Flash Part #
    //
    ​

    I use MX25L6433FM2I-08G in our design.

    //
    //  Read Command
    //

    T    he read command opcode for the SPI flash device is 0x03.I've confirmed that the RBL uses the command.

    //
    //  SPI I/F Mode
    //
     
    I use the SPI1 CS0 in 4 pin mode. The RBL requires the mode.

    //
    //  SPI Flash Read/Write Check
    //

    I'd like to say again that I tried to replace the flash device, but the issue still occured.
    So, I don't think that there is any problem with the SPI flash device. I think the issue is only during power on.
    But I'm planning to run any diagnostics for checking the R/W that you suggested.   
     
    Then I have a question. 
    I noticed that the SPI1_ENAn pin is open in our design. Which is the pin direction during boot, input or output? Do I have to use an external pullup or pulldown resistor on it?

    I'm wondering if you could check out the RBL code. 
    I'd like to make sure whether there is any conditional expression in it that read the magic word again, or not.

    Regards,
    j-breeze

  • 0 in reply to j-breeze
    TI__Guru** 116020 points
    Thanks for providing the boot command sequence. Now I understand the situation better. At the secondary bootloader level, can you indicate, if you are using a custom entry point different than _c_init00 symbol? I notice that the entry point for the SBL is in DDR, have you tried to use SHRAM or device internal memory as the entry point. After you connect to device when boot fails is the DDR configured correctly ? Does the settings in the AISGen DDR2 setting match with the GEL file DDR settings that you tested on your board.

    YOu can private message me the AIS config file using E2E messaging. After you log into E2E, you can look to the top right for messaging options or click on my profile and go to connect to private message me the file.

    Boot ROM only uses Chip select, SIMO, SOMI and CLock so enable pin is not used during boot. I am not a the right expert to comment on the pull on the enable pin so I have looped a hardware expert to comment. The bootloader is working reliably in thousands of designs that are based on this baseline so I don`t believe this to be a ROM issue but we need to figure out if this is a configuration level issue or a board design issues.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Mastermind 7560 points
    Hi Rahul,

    The SBL entry point is the same as the address of _c_init00 symbol. I will send the map file later.
    I have not tried to use device internal memory as the entry point yet. I'm going to try it and check the DDR2 settings.

    And, could you please answer my question about the RBL code?
    I understand what you mean that the RBL is working reliably in thousands of designs, but I'd really like to make sure whether there is any conditional expression in the code that read the magic word again, or not.

    Then, regarding the SPI1_ENAn pin, should I open a new thread?

    Regards,
    j-breeze
  • 0 in reply to j-breeze
    Mastermind 7560 points

    Hi Rahul,

    I doubt that an exception occur after jumping to my SBL now.
    I am so sorry to ask you many times, but could you please let me know the interrupt service vectors which the RBL sets?

    Regards,
    j-breeze

  • 0 in reply to j-breeze
    TI__Guru** 116020 points

    SOrry for the delayed response. I was tied up with high priority tasks and was out of office for some time so was not able to follow up on this topic

    the Interrupt service vectors setup by ROM can be seen in the base location of the following memory section.

    /* ARM Internal RAM Memory*/

     RAM_ARM         : o = 0xFFFF0000  l = 0x00002000  /*      8 KB */

    the initial arm vector setup by ROM appears as follows:

      .sect ".text"
  .global reset
  .global ARM_ROM_START
reset:
  b ARM_ROM_START
  b reset
  b reset
  b reset
  b reset
  b reset
  b reset
  b reset

    and the ROM idle vector is setup as follows:

    .sect ".text"
    .global reset
    .align 4
    reset:
    b reset
    b reset
    b reset
    b reset
    b reset
    b reset
    b reset
    b reset

    Hope this helps.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Mastermind 7560 points

    Hi Rahul,

    I found a problem with the DDR2 device. So, it seemed that an opcode exception occurred after jumping to my SBL in the DDR2 and jump to the reset vector address 0x700000 in DSP L2 ROM and then RBL started again.

    I really appreciate your support and I'd like to close this thread.

     

    Regards,
    j-breeze