AM437x GPMC CS0 assert problem

Hi g.f,

I will bring this to the attention of the factory team. Can you please provide information about the processor revision (top-side marking), and at what moment during boot is this issue observed?

Hi g.f.,
I have confirmed this issue on our EVM as well. I'm seeing approximately a 4ns low going glitch (drops to about 1.2V from 3.3V). I have also confirmed that this is occurring when the ROM switches the pinmux for that signal during initialization of the QSPI boot.

At this point, I don't have a legitimate workaround for your customer's board. They will have to compensate for this glitch in their FPGA. The QSPI flash on our EVMs is not affected by this glitch.

Regards,
James

Hi Biser and James,

Thank you for the reply.

I need to tell the detail of method to my customer.
What is the good method to compensate the glitch with the FPGA?
How about watching the GPMC WE/OE as well as glitch of CS by FPGA?
Or, if there are any other method , can you please suggest?

best regards,
g.f.

g.f,
the QSPI interface only has Clock, Chip Select, and 4 data signals. The FPGA shouldn't react at all without a low CS and a clock. Check the timing diagrams in the AM437x datasheet.

Regards,
James

g.f, after discussing with a co-worker, we need to clarify some things:
-Is your customer trying to use GPMC_CSn0 as a chip select to access the FPGA using the GPMC?
-Are they booting from a QSPI Flash, or are they using the QSPI interface to the FPGA?

If both are yes, then you would need to use 2 separate pins for each chip select. There are 7 GPMC chip selects to choose from (GPMC_CS0-GPMC_CS6), and the are 2 sets of pins to boot from QSPI (see table 5-35 in the TRM).

Regards,
James

Hi James,

Thank you for the reply.

>Is your customer trying to use GPMC_CSn0 as a chip select to access the FPGA using the GPMC?

Yes, they are trying to use GPMC_CSn0 to access the FPGA using the GPMC.

>-Are they booting from a QSPI Flash, or are they using the QSPI interface to the FPGA?

Yes, they are booting from a QSPI Flash.
But they are not using the QSPI interface to the FPGA.

best regards,
g.f.

Hi James,

I forgot to say that the customer already made their prototype board.
So, it is difficult to change from the GPMC CS0 to other unused CSn.

best regards,
g.f.

Hi James,

Here are the additional information.

For QSPI Boot, the customer are using the pins of Pinmux Option 1.
(Please see page.226 Table 5-35 of AM437x TRM)
So, they are using 2 separate pins for each chip select(gpmc_cs0 and qspi_csn).
gmcs_cs0 : A8 pin,
qspi_csn : AA18 pin

By the glitch of gpmc_cs0 during QSPI boot , the FPGA state machine will transit to operation state.
And the phenomenon which malfunctions at the time of original CS0 access occurs.

So, what should they do for the glitch of gmcs_cs0?

best regards,
g.f.

Hi James,

I guess there are no workaround which can be done at AM437x side because as you mentioned
that this problem occur during AM437x ROM is switching the pinmux.

So, let me change my question.

You mentioned that this problem will occur when AM437x ROM switches the pinmux.
I was understanding that ROM will switch the pinmux which is related to the boot mode only.
But as I mentioned the customer are using Pinmux Option 1 for QSPI boot which pin is not pinmux with GPMC_CS0.

Q1.
Do you mean that AM437x ROM software will switch the pinmux which is unrelated to the boot mode?
If yes, does this problem occur in other boot mode(ex. SD boot) or only QSPI boot mode?

Q2.
Does this problem occur when switching the pinmux in the application?

best regards,
g.f.

I think your best option will be to qualify the CS signal with a WR or RD strobe, as a valid access to the FPGA will always involve WR or RD strobe.
This is a small logic change inside the FPGA.

Hi Wolfgang,

Thank you for the reply.

I understood.
But I need the answer for my last post.
>Q1.
> Do you mean that AM437x ROM software will switch the pinmux which is unrelated to the boot mode?
> If yes, does this problem occur in other boot mode(ex. SD boot) or only QSPI boot mode?

>Q2.
> Does this problem occur when switching the pinmux in the application?

Because this problem occured at my customer and I need to tell the details of this problem to them.
So, I guess only TI knows the details.

best regards,
g.f.

Hi James,

It passed a month from my last post.
I need to answer to my customer, so can you please answer to the question written in my last post.

Q1.
Do you mean that AM437x ROM software will switch the pinmux which is unrelated to the boot mode?
If yes, does this problem occur in other boot mode(ex. SD boot) or only QSPI boot mode?

Q2.
Does this problem occur when switching the pinmux in the application?

best regards,
g.f.

Hi James,

I checked the GPMC_CSn0 signal from AM437x IDK board by osciloscope.

I configured the PINMUX of GPMC_CSn0 as follow by software.

************************************************

CTRL_CONF_GPMC_CSN0 Register bit[3:0]

I changed this bit's value continously as follow:

0x0(gpmc_csn0) <=> 0x7(gpio1_29)

************************************************

Durining this configuration, the glitch was on the GPMC_CSn0 pins.

I attached the file of signal, so can you please check?

From this result, I guess the glitch will occure

either during boot or pinmux configuration in user application.

Is it correct?

By the way, does AM437x ROM code configure GPMC_CSn0 pin when using QSPI boot Option 1?

I'm asking because QSPI boot option1 doesn't use GPMC_CSn0 pin and I thought ROM code only configure the pins which is needed for the boot.

I checked the other signal when configurating PINMUX, but there was no glitch on that signal.

Does glitch occur only on GPMC_CSn0 pin?

best regards,

g.f.GPMC_CSn0 Signal.zip

Hi g.f.,
signal glitches during pinmux changes can be expected. The mux controlling the signal is not glitch free, and depending on the decoding of the internal mux signals, the signal can be cycling though different sources for a short amount of time. So you may or may not see a glitch. Definitely, pinmux should only be changed during initialization when the interface is not being used. As was previous posted, you should be able to qualify the CS signal with RD or WR in the FPGA to avoid the issue.
I agree that using QSPI boot option 1 should not adjust the pinmux on that signal. Let me investigate that a bit. But ultimately, it is possible these glitches will occur with any pinmux change on any signal.

Regards,
James

Hi gf, i just tested this on the GP EVM, and I did not see the glitch when using QSPI boot option 1. Are you sure you have SYSBOOT[6]=1, which controls the pinmux option for QSPI boot? If you dump address 0x44e10040, you can verify what the device is reading for the SYSBOOT signals.

Regards,
James

Hi James,

Thank you for the reply.

Me too.
I tested QSPI boot on the GP EVM but there was no glitch occured on the GPMC_CSn0 pin.
When I tested I configured SYSBOOT[4:0] to "01010b (only QSPI boot)" and SYSBOOT[6] to "1b".
Sorry, I didn't check the address 0x44e10040. I will check tomorrow because I'm out of office today.

By the way, in May 8th you said as follow:
>I have also confirmed that this is occurring when the ROM switches the pinmux for that signal
>during initialization of the QSPI boot.

In this case, did you test QSPI boot with SYSBOOT[6]=0 which uses GPMC_CSn0 pin as QSPI_CS signal?

best regards,
g.f.

FYI,

James is out of the office for three weeks, so he will not be able to answer your question until he returns.

Regards,
Paul

Hi gf, yes that was with SYSBOOT[6]=0. So as expected, you should not see any glitches on GPMC_CSn0 with SYSBOOT[6]=1

Regards,
James