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.

AM3505 MMC Booting - Can't see any activity!!

Other Parts Discussed in Thread: AM3505

 

Hi,

In my design, I plan to boot up the AM2505 for the 1st time using the 3V3 MMC1 interface.

As such I have set the Sys_boot pins to use the following setting

Config Pins Value                                                   Peripheral Booting Order

                                                                                      1              2           3              4
Sys_boot[5] & Sys boot[4..0]....1  0  1  1  0  1     USB          UART    MMC1     XIP-NOR

                           
Sys_boot[6]...............................  1                           Ext 26M SQUARE CLK
Sys_boot[7]...............................  0                           Exter 32K OSC

On board power up I have confirmed the AM3505 to have the correct Power-Up sequence,32kHz and 26MHz clocks inputs, sys_nRESPWRON assertion/deassertion.

After PowerOnReset , on probing the MMC1_Clk(AA9) , MMC1_Dat0(AC9) and MMC1_Cmd(AB9) pins, I see NO activity. ( I was expecting to atleast see a 400 kHz identification Clock signal on the MMC1_Clk pin)

However, while I was probing around the GPMC interface for any activity I noticed that the GPMC_nCS0 was toggling! 

 

I then changed the booting sequence to Memory Booting Order as below, but saw the same result!

Sys_boot[5] & Sys boot[4..0]....0  0  1  1  0  1     XIP-NOR  USB       UART     MMC1

 

Looking around for any obvious information on the Data Sheet and the TRM, I noticed that the Ball Characteristics Table 2-1 may explain this...

As seen in the Table, the RESET REL MODE of the MMC interface is MODE = 7, while the MMC function on the pins is available only for MODE = 0. I interpret this as the MMC interface pins are configured as High-Impedance( Safe_mode) MODE 7, as such I see no activity??

While the RESET REL MODE of the GPMC interface is MODE = 0 , as well as the GPMC function on the pins is available for MODE = 0. As such I see activity!!

Q1) Can you confirm if  this is the reason why I see signal toggling on the GPMC interface BUT NOT the MMC interface?

In the case of my design, I need to wake up a dead board by first using the Uboot/UserCode from MMC interface. The code from the MMC shall be then shadowed in the attached NOR-FLASH on the GPMC. Once this is done, the MMC shall be removed and on the next power-up, the code will be loaded from FLASH.

It seemed to be quite straight forward as per section 24.4.7.6 MMC/SD Cards of the SPRUGR0B–October 2009–Revised July 2010, that the ROM code supports MMC cards!!

Q2) So is there any thing else, any external config etc, that needs to be done/configured to make the AM3505 boot from the MMC to achive the above?

 

Thank you,

Pretesh Mascarenhas

  • Pretesh, the ROM code will take care of setting the pad configuration of the MMC pins if it is trying to boot from MMC, so the RESET_REL_MODE is irrelavant.

    Check the tracing vectors to see if it is attempting to boot from MMC.  Info on tracing vectors can be found in Ch 24 of the TRM and some further explanation can be found here (info on tracing vectors is applicable to AM35x)

    http://processors.wiki.ti.com/index.php/OMAP35x_and_AM/DM37x_Initialization

    Also, when probing MMC1, ensure that you are triggering on the clock.  The MMC does not output a free running clock, so if you were just probing and not triggering, you may have missed it.

    Regards,

    James

  • Hi James!

    Thank you for your prompt response! The Tracing debug register was handy to check the booting sequence! But I still have a problem!

    My requirement : I need to have the MMC and the XIP for a fixed Sys_boot(5..0) option. Reason being, at our Manufacturing facility, the dead boards will boot up using a MMC card. So once the MMC is pull out of the board and shipped to the customer, the board should wake up by booting out of NOR Flash(XIP) on the next power-up cycle.

    So I need to have my XIP(NOR flash), 1st in the booting order, as we have strict start up time, as such we cant spend time to timeout of other option before reaching the XIP.

    Also, on my board, I have a MMC on AM3505's MMC1 interface and a NOR flash on the AM3505's GPMC interface. I don't have a boot UART/USB interface in my design.

    So the best option to get this configuration was to use, Memory Booting Order {sys_boot(5..0) => "00 1101" i.e  XIP => USB => UART => MMC1}

    However, if I do use this option, I see NO activity on the MMC interface! The table below shows the Trace Register bits for this option using a JTAG emulator.

    Seems like, the ROM boot code, detects a XIP memory ONLY(bit-33)! The MMC doesnt even get detected ( bit-38). The NOR flash is empty, BUT, it's still detected as having the Correct Memory boot Image header (bit-11) and it seems to execute the image too (bit- 22).!!!! 

    Q1) How can this happen???  I was told by a local TI representative, that the Boot code would validate the 1st few blocks of the Flash and exit to the next device if it didn't find a Valid Header!! So it was on this assumption that I chose the above booting order!

     

     

    Current tracing vector REGISTER bits sys_boot(5..0) =>
    "00 1101"
     XIP => USB =>
     UART => MMC1
    sys_boot(5..0) =>
    "001 0010"
    MMC1 => USB =>
     UART
         
    Data @ 0x4020FFB0 0x0040081B 0x0000001B 
    Data @ 0x4020FFB4 0x00000002 0x00000040
    0 - Reset 1 1
    1 - General ROM code C main 1 1
    2 - General ROM code runs after the cold reset    
    3 - Boot Booting started 1 1
    4 - Memory boot Memory booting started 1 1
    5 - Boot No more device to check    
    6 - Peripheral boot Peripheral booting started    
    7 - Boot Booting message change device    
    8 - Boot Booting message skip per. booting    
    9 - Reserved    
    10 - Reserved    
    11 - Memory boot Image header correct 1  
    12 - Peripheral boot Device initialized    
    13 - Peripheral boot ASIC ID sent    
    14 - Peripheral boot Booting message received    
    15 - Peripheral boot Image received    
    16 - Peripheral boot Peripheral booting failed    
    17 - Peripheral boot UART    
    18 - Peripheral boot USB    
    19 - Peripheral boot EMAC    
    20 - Reserved    
    21 - Peripheral boot NULL device    
    22 - Execute Image executed 1  
    23 - Reserved for non-GP devices    
    24 - Reserved for non-GP devices    
    25 - Reserved for non-GP devices    
    26 - Reserved for non-GP devices    
    27 - Reserved for non-GP devices    
    28 - Reserved for non-GP devices    
    29 - Boot Software booting configuration section 1 found    
    30 - General Software booting configuration clocking fnd    
    31 - Reserved    
    32 - Memory boot Null device    
    33 - Memory boot XIP 1  
    34 - Memory boot NAND    
    35 - Memory boot OneNAND    
    36 - Memory boot DOC    
    37 - Memory boot MMC/SD2    
    38 - Memory boot MMC/SD1   1
    39 - Memory boot XIP memory with wait monitoring    

    40 - Memory boot SPI

    So, I changed the external PU/PDs on the sys_boot pins and configured it to Memory Booting Order {sys_boot(5..0) => "001 0010" MMC1 => USB => UART}

    I DO SEE the MMC interface Clock and CMD line toggle!! ...But this is NOT the mode I want to use, as I do need to have a XIP in the Booting order before the MMC!

     

    Q2) Has TI tested all these different options ? or is the booting tables from the TRM need an update?

     

    Q3) Can you suggest how do we achieve our requirement other than doing it this way?( remember we cannot do HW resistor PUp/PDwn mods, and we need a short start-up in field)


    Q4) Can I get the Source Code for the BOOT CODE under a Company NDA with TI?

     

    Thank you

    Pretesh Mascarenhas

     

     

     

     

     

  • Hello Pretesh,

    It looks like you have something stored in the NOR that looks like x-loader.  Can you ensure the NOR is erased?  If the ROM code sees x-loader in the 1st boot option then it will never get to the MMC option.