• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 14 replies
  • Subscribers 101 subscribers
  • Views 503 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.

AM62D-Q1: QSPI boot ROM does not issue read command

Colb Uhlemann
Prodigy 50 points

Part Number: AM62D-Q1

Tool/software:

HIgh-level summary: From factory, AM62D does not boot over QSPI. The root cause is that the interface never sends the 0x6B command to read data from flash. The behavior is observed on both empty and valid, programmed flash. A workaround is switching to SPI boot, issuing an MCU_PORz, switching back to QSPI, and issuing another MCU_PORz. Once this workaround is applied, the processor boots as expected. Based on our limited data and soak time, the workaround appears to be persistent.

Occurrence rate: 100% (observed on first programming of all hardware, >100 boards)

I am a hardware engineer implementing AM62D on a custom board. The intended boot method is QSPI using CSn0 from Macronix NOR flash part MX66U2G45GXRI00. The observed behavior is that the processor cannot boot using QSPI boot mode. At minimum, the processor behaves this way if: 1) QSPI boot mode is set on first power up and all following resets/power cycles, or 2) serial NAND boot mode is set for any number of resets/power cycles and then changed to QSPI boot mode for any number of resets/power cycles. No amount of resets/power cycles in QSPI or NAND boot mode seems to prevent this behavior. 

To be explicit, QSPI boot mode means BOOTMODE[15:0] = 0b0000 0000 0001 0011. Serial NAND boot mode means BOOTMODE[15:0] = 0b0000 0000 0000 0011.

Upon detailed investigation of a brand new board, I find that the QSPI boot mode never sends any read commands to get data from the flash. Per the AM62D TRM, the boot ROM should send a 0x6B (QREAD) command using 3-byte addressing followed by 8 dummy cycles. Per the flash datasheet, this command sequence is supported.

Here is the flash signal mapping for the following scope captures:

Signal

Description

D6

RESETn

D5

CSn

D4

DQ3

D3

DQ2

D2

DQ1 (MISO)

D1

DQ0 (MOSI)

D0

SCLK

Here are the initial transactions on the QSPI interface upon release of MCU_PORz:

Each burst consists of 17 JEDEC ID reads (command 0x9F, RDID): 1 with SCLK=6.25MHz and 16 with SCLK=50MHz. The boot ROM never issues any read commands to the flash.

Switching to SPI boot mode, the interface behaves as expected. A 0x03 READ command is issued for address 0x000000. Since the flash returns all F's (empty), a second 0x03 READ command is issued for address 0x400000.

Then, upon switching back to QSPI boot mode, we observe that the 0x6B QREAD instruction for 3-byte address 0x000000 is now present!

My questions are as follows:

  1. What is the specific root cause for this behavior within the AM62D?
  2. What is TI's recommendation to ensure reliable boot throughout the lifetime of the product?
  • 0
    TI__Guru**** 225015 points

    Hello Colb Uhlemann,

    Thank you for the query.

    I suspect this is likely an issue with the bootmode input threshold.

    The bootmode output buffer series resistor used in the previous revision of the schematics 4.99K as against ~1K we use on the SK.

    There is also a 33R series resistor.

    Are you able to measure the output of the buffer after the series resistors near to the SOC bootmode inputs. 

    I suspect this should be above VIHSS spec for LVCMOS buffer.

    Would you be able to reduce the series resistor value to ~1K and do a check. 

    Regards,

    Sreenivasa

  • 0
    TI__Guru**** 225015 points

    Hello Colb Uhlemann,

    Thank you for the query.

    I suspect this is likely an issue with the bootmode input threshold.

    The bootmode output buffer series resistor used in 4.99K as against 1K we use on the SK.

    There is also a 33R series resistor.

    Are you able to measure the output of the buffer after the series resistors near to the SOC bootmode inputs.

    Would you be able to reduce the series resistor value to 1K and do a check. 

    Regards,

    Sreenivasa

  • 0
    TI__Guru**** 225015 points

    Hello Colb Uhlemann,

    Thank you for the query.

    I suspect this is likely an issue with the bootmode input threshold.

    The bootmode output buffer series resistor used in 4.99K as against 1K we use on the SK.

    There is also a 33R series resistor.

    Are you able to measure the output of the buffer after the series resistors near to the SOC bootmode inputs.

    Would you be able to reduce the series resistor value to 1K and do a check. 

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 225015 points

    Hello Colb Uhlemann,

    I wanted to check if you have the setup to connect to one of the cores through JTAG and read the devstat register.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 225015 points

    Hello Colb Uhlemann,

    During the schematic review i remember having added some comments around the QSPI interface and bootmode configuration.

    in case the above recommendations do not work, can tou please share the updated schematics through TI contact to do a quick review.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 50 points

    Hi Sreenivasa,

    Thank you for your feedback!

    I do not have JTAG access yet, but I recently ordered an XDS110 debug probe and can try reading the devstat register as soon as it arrives.

    As for the boot mode pins, my design closely resembles the reference design in this FAQ with 1k pullups and 100k pulldowns:  [FAQ] AM625 / AM623 / AM620-Q1 / AM64x / AM243x / AM62Ax / AM62Px / AM62D-Q1 / AM62L - Bootmode implementation without isolation buffers. I think we can rule this out as a source of error since the SoC correctly boots using QSPI or SPI based on the boot mode settings, per the data I shared above. During development, we have also reliably booted using SD card and xSPI, including booting from SD card as the backup interface.

    I am eager to learn more about the QSPI boot ROM and understand why the read command is missing from the boot sequence when it runs for the first time.

    Thanks,

    Colb

  • 0 in reply to Colb Uhlemann
    TI__Guru**** 225015 points

    Hello Colb Uhlemann

    Thank you.

    Do you use buffers for connecting the bootmode inputs as in the initial schematics?

    If yes, can you verify the series resistor value.

    Colb Uhlemann said:
    I am eager to learn more about the QSPI boot ROM and understand why the read command is missing from the boot sequence when it runs for the first time.

    Help me understand what you mean by first time - long power off.

    Just to confirm, can you please measure the voltage level at the bootmode inputs of the SOC.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 225015 points

    Hello Colb Uhlemann

    Please read the notes added on the above FAQ you mentioned.

    We are recommending to reduce the 100K given the IO leakage to 47K when DIP switch is used.

    In case, DIP switch is not used a pullup or pulldown is recommended.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 225015 points

    Hello Colb Uhlemann

    Checking if you made some progress?

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 50 points

    Hi Sreenivasa,

    Sorry for the delayed reply. As a side note, let's limit our discussion to the information I've provided in this post. All schematics are shared under NDA and should not be discussed here.

    Here is the boot mode information, as requested.

    Signal

    Voltage (V)

    BOOTMODE[0]

    1.774

    BOOTMODE[1]

    1.773

    BOOTMODE[2]

    0.011

    BOOTMODE[3]

    0.012

    BOOTMODE[4]

    1.773

    BOOTMODE[5]

    0.011

    BOOTMODE[6]

    0.011

    BOOTMODE[7]

    0.011

    BOOTMODE[8]

    0.015

    BOOTMODE[9]

    0.013

    BOOTMODE[10]

    0.011

    BOOTMODE[11]

    0.013

    BOOTMODE[12]

    0.011

    BOOTMODE[13]

    0.012

    BOOTMODE[14]

    0.011

    BOOTMODE[15]

    0.010

    By "first time" booting using QSPI, I mean first time since the part was manufactured. Fresh from the factory, the AM62 will not boot over QSPI until we issue the workaround of switching to SPI boot mode. Have you been able to reproduce this behavior on your side yet?

    Colb

  • 0 in reply to Colb Uhlemann
    TI__Guru**** 225015 points

    Hello Colb Uhlemann

    Thank you.

    Colb Uhlemann said:
    Occurrence rate: 100% (observed on first programming of all hardware, >100 boards)
    Colb Uhlemann said:
    By "first time" booting using QSPI, I mean first time since the part was manufactured. Fresh from the factory, the AM62 will not boot over QSPI until we issue the workaround of switching to SPI boot mode

    Can you confirm if the board that worked after switching the bootmode to xSPI and back to QSP continues to boot without any issue for multiple cycles as well as multiple bootmode configuration

    Does the board that has issue with QSPI initially work for any other boot configuration and when switched back to QSPI continue to have the issue until the bootmode is set to xSPI and back to OSPI?

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 225015 points

    Hello Colb Uhlemann

    Kallikuppa Sreenivasa said:
    Does the board that has issue with QSPI initially work for any other boot configuration and when switched back to QSPI continue to have the issue until the bootmode is set to xSPI and back to OSPI?

    have you tried doing power cycling when the QSPI boot had issues without changing the configuration and see the issue to persist.

    Regards,

    Sreenivasa

  • 0
    TI__Guru 57705 points

    Hi,

    Thanks for mentioning in detail.

    Colb Uhlemann said:
    A workaround is switching to SPI boot, issuing an MCU_PORz, switching back to QSPI, and issuing another MCU_PORz.

    So this is consistently seen. I would like to clarify one thing.

    When you set initially to QSPI bootmode, then no commands seen on the line, so you perform the following workaround.

    • Set to SPI bootmode
    • Issue power reset(cold or hot?) -> When you issue this, are the expected commands being sent for SPI bootmode?
    • Set to QSPI
    • Issue power reset(cold or hot?) -> When you issue this, then the booting happens perfectly.

    Looking forward to your response.

    Regards,

    Vaibhav