• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 6175 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.

AM5728: Boot sequence stuck on QSPI

Chris Welch66
Expert 1790 points
Part Number: AM5728


We are developing an AM5728 product based on the EVM design.  We are in the second spin of our hardware.

We've setup the boot order to be QSPI-4 SD USB.

There is no code currently in the QSPI-4 NOR FLASH, we want it to boot from SD.  If we change the boot order to SD first, the card boots fine.

We get an data abort exception with the QSPI-4 first in the boot order.  That is, the processor ends up stuck in the dead loop at 0x3808c.

Unfortunately, the documentation doesn't spell out what this means.

Can some one explain what this problem is?

Thanks!

  • 0
    TI__Guru**** 393215 points
    The factory team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Expert 1790 points
    I think I've found our problem. Our design is missing the qspi1_rtclk signal. I had a look at the TI AM5728 IDK schematics and in the TRM it indicates the signal must be connected. Working with our H/W folks to correct.

    Would appreciate if you could let me know what the error means though. I'm some what surprise that the boot loader gets stuck instead of continuing onto the next device (SD in our case) to boot.

    The information will be helpful in the event we continue to have difficulties once the problem is corrected.
  • 0 in reply to Chris Welch66
    Expert 1790 points
    The missing qspi1_rtclk isn't the problem. We are back to trying to understand what the fundamental problem is.

    At this point it looks like the problem documented by errata i386, "QSPI-4 Boot Mode Is Not Functional".

    Hopefully someone can provide some insight as the documentation is contridictory.

    1) The TRM Table 24-355 pg 5951 indicates the qspi1_rtclk is not required if you are using SPI mode 3.
    2) The TRM section 33.3.7.5 indicates that the boot loader using mode 3. So the missing qspi1_rtclk connection isn't the source of our problem.
    3) The same section of the TRM, however, says "ROM will not perform any quad-enable sequence nor bank register update". This could be our problem as our FLASH is QE disabled by default, but....
    4) Errata i861 says "The ROM code writes to a non-volatile bit (QE bit) to enable quad mode". This disagrees with #3 TRM documenation.

    The problem described in errata i861 resembles our problem:

    "QSPI-4 boot modes do not function. The ROM code writes to a non-volatile bit (QE bit)
    to enable quad mode and then attempts the first read access before the flash device is
    ready. The flash does not respond and bad data is read and executed by the ROM. The
    flash device models used for verification failed to model this characteristic of the flash
    properly."

    The errata indicates that this is applicable to SR 1.0.

    We are using SR 2.0.

    Can some one please help with the following questions?:

    a) What does the error we are getting mean? (data abort exception, dead loop hang in the PROM code)
    b) Which is correct between #3 and #4? Does or doesn't the AM5728 do a quad mode enable?
    c) What is the behavior for i861 for the SR 2.0 part? Is the work around still required?

    Thanks!
  • 0 in reply to Chris Welch66
    Expert 1790 points
    Nothing heard so we are engaging our local field engineer.
  • 0 in reply to Chris Welch66
    Expert 1790 points
    Still haven't heard anything from our local field engineer.

    Have found that the data abort exception indicates an error with the TI boot PROM code. We have nothing in the QSPI NOR FLASH so the exception is occurring due to an error occurring during execution of the TI boot PROM code.

    www.embedded.com/.../How-to-use-ARM-s-data-abort-exception
  • 0 in reply to Chris Welch66
    TI__Guru* 89485 points

    Chris, i861 does not apply since you are using SR2.0. 

    My guess is what is happening is that the ROM believes there is a valid image in the QSPI, and thus tries to execute the instructions and ends up at the data abort.  In the TRM it states that a booting image is considered to be valid if the 1st 4 bytes are not equal to 0x0 or 0xFFFFFFFF.  So something is going wrong with the first few reads that the ROM is doing, and it is inadvertently reading something other than zeros or all Fs.  

    Are you able to put a scope on the QSPI signals to see if the signals are valid and the QSPI commands and data are correct?  Something may be wrong with this interface on the board.  Is there anything different between your design and the EVM you referred to?

    Regards,

    james

  • 0 in reply to JJD
    Expert 1790 points

    Thanks for the follow up.

    There are two differences in the implementation.  

    The first is that we don't have the return clock signal wired, however, the TRM indicates it isn't necessary for mode 3 SPI which is what is used by the boot loader.

    The second is a lack of pull ups on the /hold /wp signals.  This should still work as the part will be put into quad mode and these signals will then become data 2&3.  None the less, I had our hardware folks put pull ups on the signals and it still fails.  However, it fails with a prefetch exception instead of a data execution exception.

    Sounds like your suggestion to scope it is the best next step.

    However, can you clarify which is correct, the TRM or the errata regarding quad enable?

    Section 33.3.7.5 of the TRM, says "ROM will not perform any quad-enable sequence nor bank register update". This could be our problem as our FLASH is QE disabled by default, but....

    Errata i861 says "The ROM code writes to a non-volatile bit (QE bit) to enable quad mode". This disagrees with TRM section 33.3.7.5.

    Thanks!

     

  • 0 in reply to Chris Welch66
    TI__Guru* 89485 points

    Chris, i think the errata is referring to the SR1.0 implementation, and doesn't apply to the SR2.0 implementation that the TRM refers to.  So they sound contradictory, but i think they are referring to 2 different ROMs from 2 different versions of the chip.  I will see if we can get this clarified in the errata.

    The QE bit is typically set when programming the QSPI flash.  In your case, what may be happening is that the ROM is expecting to read in quad mode, but the flash device, with QE=0 by default, is only responding on data0.  Thus, data1-3 is not being driven by the flash.  Having pull-ups on data1-3 should take care of this, but maybe you need to double check this with the scope.

    The prefetch abort just means that it is trying to execute an invalid instruction,

    The goal is to ensure the data bus that the ROM uses is reading all zeros or all Fs, so that is assumes an invalid image and moves on to the next boot source.

    Regards,

    james

  • 0 in reply to JJD
    Expert 1790 points

    If I follow you correctly, you are saying that potentially the SR 1.0 boot code did quad enable, but the SR 2.0 boot code doesn't.

    If this is correct, we won't be able to use our part with QSPI-4 boot mode because quad enable is off by default on our FLASH part, a Winbond 25Q16.  

    I find this odd as my understanding is that most parts are not quad enabled by default so I was surprised by this in the TRM. 

    It would be appreciated if you could confirm what the quad enable behaviour for SR 2.0 boot PROM is.

    Thanks!

  • 0 in reply to Chris Welch66
    TI__Guru* 89485 points

    Hi Chris, it is true that most QSPI flash devices are not quad enabled by default.  However, the QE (quad enable) bit in the device is non-volatile, and this bit is typically programmed when flashing an image to the memory. 

    So after the first time it is programmed, if the programming cycle sets QE=1, the flash will power up in quad mode, and thus the ROM can boot from it in quad mode.

    In the unique situation where you have a fresh QSPI (ie, one that has never been programmed, and thus QE=0), the QSPI will only drive one data bit, thus the other bits will need to be taken care of so that when the ROM does attempt quad mode, so all bits are read as 0xF.  Some QSPIs, like the one on the EVM, have internal pull ups on data1-3 to help with that.  I noticed on the Winbond part you cite, it doesn't have pullups, so this would need to be taken care of on the board.

    The alternative would be, instead of putting pull ups on the board, that when you have a newly build board, program the QE=1 (even if you don't program an image).  This will set the QSPI to quad mode by default, and the ROM should read all 0xF and move on to the next boot source.

    Regards,

    James 

  • 0 in reply to JJD
    Expert 1790 points

    Thanks for the update James, we'll try your suggestion and see how it goes.

    I'm confused though by your statement:

    Some QSPIs, like the one on the EVM, have internal pull ups on data1-3 to help with that.

    Are you referring to the AM5728 QSPI or the NOR FLASH in this context?

    Thanks!

  • 0 in reply to Chris Welch66
    TI__Guru* 89485 points
    Sorry, i wasn't specific. On the AM572x IDK, we have a Spansion (S25FL256S) flash memory. Its datasheet states that there are internal pullups when QE=0. So this keeps the signals in a high state, even without pullups on the board. This may be the reason we have not seen your specific issue on this board. I don't see a similar statement in the Winbond flash, which may mean those signals are floating during boot if QE=0.

    Regards,
    James
  • 0 in reply to JJD
    Expert 1790 points

    Thanks, we have another respin of the board coming up.  I'll forward this to our H/W folks for implementation.