Using the pad override settings in flexspi_nor_config_t

[houe]

I am attempting to change the FlexSPI boot pad settings (drive strength, slew speed, etc.) on an MIMXRT1021DAG5A mcu. We are attempting to improve the signal quality (minimize overshoot and such) for our custom PCB.

However, I have come across some unexpected behavior when using the 4 pad override settings (csPadSettingOverride, sclkPadSettingOverride, dataPadSettingOverride, and dqsPadSettingOverride) in the flexspi_nor_config_t structure (found in evkmimxrt1020_flexspi_nor_config.c file).

The DQS pad settings don't seem to be getting set properly (See 1st picture below). The CS, SCLK, and data pads settings are working, but the DQS settings don't seem to take.

Some more experimentation seems to show the DQS pad settings get set to whatever the CS pad settings are (see 2nd pic below). This might be a bug in the boot loader?

I'm not sure what logic is in the boot loader (I don't think we have the source code for that), so I'm looking for some help figuring out what is going on here. Thanks.

DQS taking CS settings?

[nickwallis]

Does this thread help at all?

https://community.nxp.com/t5/i-MX-RT/target-crashes-writing-to-register-SW-MUX-CTL-PAD-GPIO-SD-B1-05...

-Nick

[houe]

That thread discusses the DQS pad and how/when it can be used as a GPIO. In my case I am using the pad as DQS - we need it. So no I don't think that thread helps answer my question.

[mjbcswitzerland]

Hi

If the ROM loader is not responding as expected to configuration values you can simply overwrite the setting that you want as soon as your code starts up. This will avoid concerns about potential ROM loader issues because you still have full control over such details.

Whether it should be noted as an errata if it is not following your setup is of course another point...

Regards

Mark
uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements

[houe]

Yes. That will be a plan B. Its not ideal because for emissions and such we would rather not have the pins configured wrong even if for a few milliseconds at boot up.