• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Subscribers 100 subscribers
  • Views 1829 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.

C6748 boot problem

Dieter Vogel
Intellectual 390 points

I am using Version 1.9 of AIS Gen and my device type d800k006.  I am trying to boot with NOR flash.  I can create the boot file with no problem, but when I put that boot file in flash at address 0x60000000 the DSP does not boot.  I told AISGen to use the same DSP application file (.out) that I use with the emulator.  I setup AISGen with the same PLL0, PLL1, DDR, PSC and Pinmux settings that I use when emulating.

  I have confirmed that the flash has the boot file in it.  I was initially concerned about the endianness of the boot file in flash.  When I read back the  boot file from flash I read (in 8 bit C style) I read 0x21 0x00 0x00 0x00 0x54 0x49 0x50 0x41... which seems correct.

The only application file that I provided AISGen was the .out file.  The literature suggests that I do not need to enter an Entrypoint.  Is that true?

When I connect the emulator to the device, it seems as if the flash is in 8 bit mode, although I set it up in AISGen as 16 bit (suggesting it is not loading the AIS file from flash). 

Are there any other things I can do to debug this problem?

  • 0
    TI__Guru** 116170 points

    Dieter,

    You can debug the issue, using the OMAPL Debug Gel file provided below:

    http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

    This reads your device state and lets you know where the boot is held up.please ensure you are creating the boot image using the right ROM boot version in the AISGen tool. Also check the boot pins latched at power on reset using the output of the GEL file and see if there is a error code thrown by the ROM boot loader. Looking at the program counter(PC) output (also provided by the GEL file) and correlating it with the map file of your application, you can determine what part of the boot code or the application initialization is causing the issue.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 390 points

    Thank you.  The Gel file suggested a ROM issue:

    ROM Status Code: 0x00000005
    Description: Peripheral Open Failed

    What do you think could cause this?  Is there a document that describes ROM status codes in more detail?

  • 0 in reply to Dieter Vogel
    TI__Guru** 116170 points

    Dieter,

    The error message suggests that the ROM boot loader is not able populate the NOR flash information required to read from the boot media. Are you sure you are using CS2 of the EMIF, address and data lines done correctly for specified bus width. Is this non-AIS or AIS NOR boot mode?

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 390 points

    Rahul,

    Thank you again for the assistance.   I am definitely using CS2 of the EMIF.  I am able to program the flash correctly and read it back correctly.  I am accessing the flash in 16 bit mode and I setup CS2 in the AIS generator as such (I am using AIS NOR boot mode).  The circuit for the flash chip select uses both CS2n and CS3n anded together  to generate the flash chip_selectn (this is designed per the TI suggestion).

    Dieter

     

  • 0 in reply to Dieter Vogel
    Prodigy 70 points

    Are you able to connect to the chip in CCS? If so, open a memory window and look at the contents of 0x60000000 to see if your image is in there. If you don't see it, check the EMIF config registers and make sure it is correctly set to 16-bit with the correct timings you used. It might indicate wrong NOR config settings in your AIS file.

    Sandip

  • 0 in reply to Sandip Patel
    Intellectual 390 points

    I can connect just fine with CCS.  I see the image at 0x60000000 and I can read the image back and confirm it is correct.

    Dieter

  • 0 in reply to Dieter Vogel
    Prodigy 70 points

    When you connect, theres no GEL file loaded that might be doing some additional configuration, right?

    Can you post the entire output of the debug GEL file too?

  • 0 in reply to Sandip Patel
    Intellectual 390 points

    Thanks again for the help.  I am not using any GEL files.  Below is the output from the debug GEL:

    ---------------------------------------------
    |             Device Information            |
    ---------------------------------------------
    DEV_INFO_00 = 0x1B7D102F
    DEV_INFO_01 = 0x00000000
    DEV_INFO_02 = 0x00000002
    DEV_INFO_03 = 0x00000002
    DEV_INFO_04 = 0x00000000
    DEV_INFO_05 = 0x000003E0
    DEV_INFO_06 = 0x00000080
    DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 0-0-6338559-4-26-37
    DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 2,0,0,15076
    -----
    DEV_INFO_17 = 0x00030003
    DEV_INFO_18 = 0x00000000
    DEV_INFO_19 = 00000
    -----
    DEV_INFO_20 = 0x30303864
    DEV_INFO_21 = 0x3630306B
    DEV_INFO_22 = 0x00000000
    DEV_INFO_23 = 0x00000000
    -----
    DEV_INFO_24 = 0x0402501A
    DEV_INFO_25 = 0x0060B7FF
    DEV_INFO_06 = 0x00000080
    DEV_INFO_26 = 0x75C80002


    ---------------------------------------------
    |               BOOTROM Info                |
    ---------------------------------------------
    ROM ID: d800k006
    Silicon Revision 2.0
    Boot pins: 2
    Boot Mode: NOR

    ROM Status Code: 0x00000005
    Description: Peripheral Open Failed

    Program Counter (PC) = 0x00712144

    ---------------------------------------------
    |              Clock Information             |
    ---------------------------------------------

    PLLs configured to utilize crystal.
    ASYNC3 = PLL0_SYSCLK2

    NOTE:  All clock frequencies in following PLL sections are based
    off OSCIN = 24 MHz.  If that value does not match your hardware
    you should change the #define in the top of the gel file, save it,
    and then reload.

    ---------------------------------------------
    |              PLL0 Information             |
    ---------------------------------------------

    PLL0_SYSCLK1 = 24 MHz
    PLL0_SYSCLK2 = 12 MHz
    PLL0_SYSCLK3 = 8 MHz
    PLL0_SYSCLK4 = 6 MHz
    PLL0_SYSCLK5 = 8 MHz
    PLL0_SYSCLK6 = 24 MHz
    PLL0_SYSCLK7 = 4 MHz

    ---------------------------------------------
    |              PLL1 Information             |
    ---------------------------------------------

    PLL1_SYSCLK1 = 24 MHz
    PLL1_SYSCLK2 = 24 MHz
    PLL1_SYSCLK3 = 24 MHz

    ---------------------------------------------
    |              PSC0 Information             |
    ---------------------------------------------

    State Decoder:
     0 = SwRstDisable (reset asserted, clock off)
     1 = SyncReset (reset assered, clock on)
     2 = Disable (reset de-asserted, clock off)
     3 = Enable (reset de-asserted, clock on)
    >3 = Transition in progress

    Module 0: EDMA3CC (0)        STATE = 0
    Module 1: EDMA3 TC0          STATE = 0
    Module 2: EDMA3 TC1          STATE = 0
    Module 3: EMIFA (BR7)        STATE = 3
    Module 4: SPI 0              STATE = 0
    Module 5: MMC/SD 0           STATE = 0
    Module 6: AINTC              STATE = 3
    Module 7: ARM RAM/ROM        STATE = 3
    Module 9: UART 0             STATE = 0
    Module 10: SCR 0 (BR0/1/2/8)  STATE = 3
    Module 11: SCR 1 (BR4)        STATE = 3
    Module 12: SCR 2 (BR3/5/6)    STATE = 3
    Module 13: PRUSS              STATE = 0
    Module 14: ARM                STATE = 0
    Module 15: DSP                STATE = 3

    ---------------------------------------------
    |              PSC1 Information             |
    ---------------------------------------------

    State Decoder:
     0 = SwRstDisable (reset asserted, clock off)
     1 = SyncReset (reset assered, clock on)
     2 = Disable (reset de-asserted, clock off)
     3 = Enable (reset de-asserted, clock on)
    >3 = Transition in progress

    Module 0: EDMA3CC (1)        STATE = 0
    Module 1: USB0 (2.0)         STATE = 0
    Module 2: USB1 (1.1)         STATE = 0
    Module 3: GPIO               STATE = 0
    Module 4: UHPI               STATE = 0
    Module 5: EMAC               STATE = 0
    Module 6: DDR2 and SCR F3    STATE = 0
    Module 7: MCASP0 + FIFO      STATE = 0
    Module 8: SATA               STATE = 0
    Module 9: VPIF               STATE = 0
    Module 10: SPI 1              STATE = 0
    Module 11: I2C 1              STATE = 0
    Module 12: UART 1             STATE = 0
    Module 13: UART 2             STATE = 0
    Module 14: MCBSP0 + FIFO      STATE = 0
    Module 15: MCBSP1 + FIFO      STATE = 0
    Module 16: LCDC               STATE = 0
    Module 17: eHRPWM (all)       STATE = 0
    Module 18: MMC/SD 1           STATE = 0
    Module 19: UPP                STATE = 0
    Module 20: eCAP (all)         STATE = 0
    Module 21: EDMA3 TC2          STATE = 0
    Module 24: SCR-F0 Br-F0       STATE = 3
    Module 25: SCR-F1 Br-F1       STATE = 3
    Module 26: SCR-F2 Br-F2       STATE = 3
    Module 27: SCR-F6 Br-F3       STATE = 3
    Module 28: SCR-F7 Br-F4       STATE = 3
    Module 29: SCR-F8 Br-F5       STATE = 3
    Module 30: Br-F7 (DDR Contr)  STATE = 3
    Module 31: L3 RAM, SCR-F4, Br-F6 STATE = 3

    Dieter

  • 0 in reply to Dieter Vogel
    TI__Mastermind 18130 points

    Hi Dieter,

    Have you by chance looked at the data coming off the pins when you first boot up? You should see the CS2 line go low a few times as it is reading in the first four bytes of data. The ROM will return this type of error code when it determines an invalid configuration (i.e. it does not read in 0x00000021 per your configuration above). In fact, it should not have even tried to read in the magic number for AIS boot yet.

    How did you program in the contents of your AIS binary into the flash? Keep in mind that the first byte would have to be done in bytes rather than shorts as the EMIFA is configured as an 8-bit bus coming out of reset. The RBL must read in the first four bytes 8-bits at a time using incrementing addresses (0x0, 0x1, 0x2 and 0x3 are different in an 8-bit device than 16-bit device).

    It sounds like you are able to read in the data correctly via the memory window, but I am uncertain if the EMIFA is still configured for 8-bit or if it is already set to 16-bit?

  • 0 in reply to TimHarron
    Intellectual 390 points

    Tim,

    I have not used a logic analyzer on the flash pins at bootup yet, that is probably going to be the next step. 

    I programmed the AIS binary into flash via my own tool through the UART.

    It is interesting that when I power on the board and connect CCS and look at the memory window for the flash I sometimes see 0xFFFF0021, 0xFFFF4954, 0xFFFF590D, etc.  When I load the code and run with the emulator and CCS then the data looks correct (0x00000021, 0x41504954, 0x5853590D).  It looks like sometimes when the DSP powers up, the flash does not read correctly. 

    As far as the ordering of the first 32 bit word in the flash, if I put CCS memory view in 8 bit mode, the first 12 bytes read 0x21, 0x00, 0x00, 0x000, 0x54, 0x49, 0x50, 0x41, 0x0D, 0x59, 0x53, 0x58.  Is that correct?

  • 0 in reply to Dieter Vogel
    TI__Mastermind 18130 points

    Dieter Vogel said:
    It is interesting that when I power on the board and connect CCS and look at the memory window for the flash I sometimes see 0xFFFF0021, 0xFFFF4954, 0xFFFF590D, etc.

    You mentioned before you are not regularly using a GEL file, but I would like to confirm that you are not using one in this case.

    Dieter Vogel said:
    When I load the code and run with the emulator and CCS then the data looks correct (0x00000021, 0x41504954, 0x5853590D).  It looks like sometimes when the DSP powers up, the flash does not read correctly.
    Same clarification, and what code are you loading via emulator? Does it have EMIFA configuration code?

    Basically, have you verified that none of the EMIFA registers are different between when you read 0xFFFF0021 and 0x00000021? As an example if you wrote 0x12345678 into the flash as a 16-bit memory when you try to read it as an 8-bit memory you would read back 0x34347878 - it doubles the LSB for each 16-bit portion.

    Dieter Vogel said:
    As far as the ordering of the first 32 bit word in the flash, if I put CCS memory view in 8 bit mode, the first 12 bytes read 0x21, 0x00, 0x00, 0x000, 0x54, 0x49, 0x50, 0x41, 0x0D, 0x59, 0x53, 0x58.  Is that correct?
    0x00000021 is good for the first word, 0x41504954 is good for the magic word, and 0x5853590D is good for the first AIS op code (Function Execute Command).

  • 0 in reply to TimHarron
    Intellectual 390 points

    TimHarron said:

    It is interesting that when I power on the board and connect CCS and look at the memory window for the flash I sometimes see 0xFFFF0021, 0xFFFF4954, 0xFFFF590D, etc.

    You mentioned before you are not regularly using a GEL file, but I would like to confirm that you are not using one in this case.

    I am not using a GEL file at all.

    Dieter Vogel said:
    When I load the code and run with the emulator and CCS then the data looks correct (0x00000021, 0x41504954, 0x5853590D).  It looks like sometimes when the DSP powers up, the flash does not read correctly.
    Same clarification, and what code are you loading via emulator? Does it have EMIFA configuration code?

    When I said that I loaded the code via the emulator I mean the code project that initally sets up PLLs, chip selects(it sets flash chip select to16 bits), etc. then runs the project. 

    Basically, have you verified that none of the EMIFA registers are different between when you read 0xFFFF0021 and 0x00000021? As an example if you wrote 0x12345678 into the flash as a 16-bit memory when you try to read it as an 8-bit memory you would read back 0x34347878 - it doubles the LSB for each 16-bit portion.

    I have verified that EMIFA registers are all the same when I read 0xFFFF0021 and when I read 0x00000021.  If i change the flash memory to 8 bit the data looks like you mentioned above.  This is only when I power on the board then connect CCS via the emulator and view memory.  I do not load any code or run any GEL files.

    Dieter Vogel said:
    As far as the ordering of the first 32 bit word in the flash, if I put CCS memory view in 8 bit mode, the first 12 bytes read 0x21, 0x00, 0x00, 0x000, 0x54, 0x49, 0x50, 0x41, 0x0D, 0x59, 0x53, 0x58.  Is that correct?
    0x00000021 is good for the first word, 0x41504954 is good for the magic word, and 0x5853590D is good for the first AIS op code (Function Execute Command).

    [/quote]

    I appreciate your help, Tim.

  • 0 in reply to Dieter Vogel
    TI__Mastermind 18130 points

    Dieter Vogel said:
    I am not using a GEL file at all.

    The reason I asked is because the EMIF data lines all have internal pull-up resistors, so unless you are pulling them down the upper data bits would show up as '1' on a 32-bit read. If you have verified that the EMIF CE1 is not configured for 32-bit memory this should be moot, but that is the only reason I can think of for the 0xFFFFnnnn mask.  

    Dieter Vogel said:
    When I said that I loaded the code via the emulator I mean the code project that initally sets up PLLs, chip selects(it sets flash chip select to16 bits), etc. then runs the project.
    Safe to assume the project fits inside your L2? If you are not running a GEL file the DDR EMIF would not know how to talk to an external SDRAM.

    Dieter Vogel said:
    I have verified that EMIFA registers are all the same when I read 0xFFFF0021 and when I read 0x00000021.  If i change the flash memory to 8 bit the data looks like you mentioned above.  This is only when I power on the board then connect CCS via the emulator and view memory.  I do not load any code or run any GEL files.
    Keep in mind that only the first 4 bytes in flash need any sort of special treatment. This is only because the RBL assumes an 8-bit flash which is exactly why it reads that first word. If you have the CE2 space set up as an 8-bit memory (CE2CFG.ASIZE = 00b) and the first word shows up as 0x00002121 then the RBL will fail as it expects bits 12-31, 6-7 and 1-3 to be zero (RSVD), 8-11 to correspond to the COPY field (not used in NOR AIS), 4-5 as METHOD (AIS NOR boot), and 0 as ACCESS (16-bit vs. 8-bit). If the RBL detects that any of the RSVD bits are non-zero it determines that it did not properly read in this value and the boot process will die.

  • 0 in reply to TimHarron
    Intellectual 390 points

    Tim,

    I am not sure what you mean by EMIF CE1 configured as 32 bit memory. 

    The project does fit in the L2. 

    Looking at the debug Gel output would you think that the ROM is failing to read the first word or could it be failing after reading more of the flash?

    Is there anything else to try other than tack on wires and look at the address and data lines with a logic analyzer?

    Would it do any good to  send you my AIS output file?

    Thanks again,

    Dieter

  • 0 in reply to Dieter Vogel
    TI__Mastermind 18130 points

    Sorry, I am getting my parts and peripherals confused. I meant CE2, and as you already know there is no 32-bit configuration on EMIFA. 

    I think it could be useful to see the AIS file. I do believe it is failing to read the first word as you should receive an error about invalid op codes or some such if it gets past that first word. 

  • 0 in reply to TimHarron
    Intellectual 390 points

    Tim,

    I tried to attach my ais file, but it did not seem to work.  Do you want to send me your e-mail and I will send it to you.  My e-mail is dvogel@drs-rsta.com.

    Thanks.

  • 0 in reply to Dieter Vogel
    Intellectual 580 points

    I am having the same problem, posted in another thread:

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/229907/810651.aspx#810651

    What was the solution?

    Mary

  • 0 in reply to Mary Frantz
    TI__Mastermind 18130 points

    Mary,

    Dieter's issue was resolved by fixing a board-level problem. I recommend reading through the earlier portions of our conversation, and I will subscribe to your thread for follow-up.