• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 592 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.

ROM code tricky - Why XIP NOR Flash boot mode holds the GPMC_CSn2?

James He
Prodigy 70 points
Other Parts Discussed in Thread: AM3359

Hi,

We hit a problem when booting AM3359 from NOR Flash, here is the details:

We picked up the XIP-NOR Flash boot mode with SYSBOOT pin config set to 0x411A.

However, after the chip come out of reset, both GPMC_CSn0 and GPMC_CSn2 (ball V9 of the ZCZ package) are asserted, the assertion of CSn0 is expectable for boot flash access, but why GPMC_CSn2 has been asserted too? is that a bug in ROM code, or for any other special things?

Unfortunately, in our current design, the CSn2 is connected to another device and the assertion of this chip select will mess up the flash access during the boot.

Since there's no source for the ROM code, could anybody from TI can help to check the ROM code? Thanks a lot.

Regards

James.

  • 0
    TI__Guru**** 393215 points
    Hi James,
     
    Your SYSBOOT setting seems correct. The GPMC_CSn2 issue you report, could it be caused by a problem on the PCB itself? I can't see how ROM code will cause two chip-select signals to go active at the same time.
     
    Best Regards
    Biser 
  • 0 in reply to Biser Gatchev-XID
    Prodigy 70 points

    Hi Biser,

    Thanks for the check, actually we have basically checked the schematic/pcb before I open this thread, another check is after we boot the board from the 2nd source (i.e. uart0, as flash boot will fail because of the CS2 mulfunction), both devices that connect to CS0 and CS2 can be accessed well.

    Anyway, with your confirmation on the ROM code behavior, we can further check the entire power/reset cycle's signal and design, and try to bottom out the root cause.

    Regards,

    James.

  • 0
    Prodigy 40 points

    Looking at Table 26-10 and its footnotes it is stated that GPMC_CSN2 and GPMC_BE1N are driven with the BE1N signal in XIP_MUX2 mode.

    The SYSBOOT configuration you have above looks like it selects XIP_MUX2.

    Perhaps this helps to explain the behaviour you were seeing? Did you get any further with this issue since you posted it?

    Also note ref. the latest revision of the AM335x Technical Reference Manual Rev. J (spruh73j), Table A-1 (changes from Rev. I) "Changed XIP_MUX1 reference to XIP_MUX2 in overview of Section 26.1.6, Fast External Booting."

    Regards,

    Richard.

  • 0 in reply to Richard Harrison1
    TI__Guru**** 393215 points
    This is an old thread. The latest TRM is correct. GPMC_CS2 should not be used if XIP_MUX2 mode is used for booting.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 40 points

    Biser,

    Thanks for the response. I realise that this is an old thread but the question is relevant to a new design we are working on. Note that I am referring to the latest TRM in which it is stated (Table 26-10, footnote 2) "The GPMC_CSN2 and GPMC_BE1N terminals are driven in this mode with the BE1N signal."

    Does this not mean that the GPMC_CSN2 pad (V9, ZCZ) is driven when in XIP_MUX2 mode?

    Regards,

    Richard.

  • 0 in reply to Richard Harrison1
    TI__Guru**** 393215 points
    Yes, it does. Sorry, perhaps I wasn't clear enough. If you have a GPMC device connected to CS2 this may (and very likely will) cause a bus conflict during XIP_MUX2 boot (which is from CS0).