2418471_en-US

[#1]

FLS Driver Support for Micron MT35XU01GBBA on S32G399

Hi NXP Experts,

I am an AUTOSAR software engineer working with the S32G399 platform.

From my understanding, the MX25UW51245GXDR00 serial NOR Flash is mounted on the S32G-VNP-RDB3 board. The FLS driver examples provided in SW32G_RTD_4.4_5.0.0_QLP07 indicate support for the S32G-VNP-RDB3 board, so I assume the NXP FLS driver has been validated with the MX25UW51245GXDR00 device.

I have recently received a customer board that uses a Micron MT35XU01GBBA serial NOR Flash instead.

Could you please clarify whether the FLS driver included in SW32G_RTD_4.4_5.0.0_QLP07 supports the Micron MT35XU01GBBA device?

If support is available, are there any specific configuration changes or limitations that I should be aware of when migrating from the MX25UW51245GXDR00 to the MT35XU01GBBA?

Re: FLS Driver Support for Micron MT35XU01GBBA on S32G399Thank you so much!!!Re: FLS Driver Support for Micron MT35XU01GBBA on S32G399

Hi,

Thanks for sharing the details. I will review the relevant parameters and requirements to consider when migrating the QSPI Flash from the MX25UW51245GXDR00 to the Micron MT35XU01GBBA, including FLS driver support, required configuration changes, and any potential limitations.

I will get back to you with more details once I complete the review.

Best regards.

Re: FLS Driver Support for Micron MT35XU01GBBA on S32G399

Thank you for your patience while I reviewed all the information.
As you may already know the FLS configuration used by the S32G-VNP-RDB3 example is device-specific. And thus includes parameters such as the flash ID, memory geometry, page size, erase size, command LUTs, address cycles, dummy cycles, reset sequence, and the transition between SPI and OPI modes that need to be configured for each device. Therefore, the Macronix configuration cannot be reused for the Micron device.

The main differences to consider are:
Memory size: The Macronix device is 512 Mb, whereas the MT35XU01GBBA is a 1 Gb device implemented with two stacked 512 Mb dies. The FLS address range and memory size must therefore be updated accordingly.
Interface and timing: The Micron device uses the 1.8 V Xccela interface and supports Octal SDR/DDR operation. It supports up to 166 MHz in SDR and up to 200 MHz in DDR with DQS. The controller mode, DDR/SDR setting, DQS sampling, DLL/timing parameters, and dummy cycles must be configured according to the Micron device and the board design.
Command sequences: The read, program, erase, register-access, and mode-transition LUTs must be recreated for the Micron command set. For example, the Micron device uses Octal read/program commands and has separate 4-byte command variants; these are different from the Macronix command sequences.
Addressing and geometry: The Micron device supports 3-byte and 4-byte addressing. In Octal DDR mode, 4-byte addressing is required. The Micron data sheet specifies a 256-byte program page, 128-KB uniform sector erase, and 4-KB/32-KB subsector erase options. These values must be reflected in the FLS memory and sector configuration.
Device identification: The expected JEDEC identification is different. The Micron data sheet specifies manufacturer ID 0x2C, memory type 0x5B for the 1.8 V device, and capacity code 0x1B for 1 Gb. The FLS read-ID sequence and expected device ID must be updated; the exact extended ID should also be verified against the full ordering code on the customer board.
Programming limitation in Octal DDR: The Micron data sheet specifies even bus-transition requirements for Octal DDR programming. Odd start or end addresses may require alignment or 0xFF padding, so page-program handling should be verified carefully.
Reset and startup state: The Micron reset sequence and the device's volatile/nonvolatile configuration registers must be checked. The controller and memory must start in the same protocol and timing mode after reset. If XIP or DDR boot is used, the boot configuration must also match the exact Micron ordering option.

It is worth mentioning that I have checked internally and the MT35XU01GBBA has been used successfully in the past, however, the integration was done on the Linux side, thus I can assure the hardware peripheral supports the memory, however, I will need to check if there is any particular concern on the FLS driver. I have escalated this question to the internal team, I will share their feedback as soon as I receive it.

For reference:

• AN13563: S32G QuadSPI Deep Dive: AN13563: S32G QuadSPI Deep Dive – Application note
• S32G QSPI NOR customization guide: S32G QSPI Nor customization doc
• UBOOT/Linux BSP support for 1Gbit Micron MT35XU01GBBA: https://community.nxp.com/t5/S32G-Internal-Community/gh-p/52149

Best regards, 
Aldo.

Re: FLS Driver Support for Micron MT35XU01GBBA on S32G399

Your information is very helpful. Thank you for your support.

Could you please provide a configuration example for MT35XU01GBBA? I would like to use it as a reference when configuring the Fls module in my EB tresos project.

Additionally, I am unable to access the following link:

• UBOOT/Linux BSP support for 1Gbit Micron MT35XU01GBBA: https://community.nxp.com/t5/S32G-Internal-Community/gh-p/52149

Could you please share the relevant information or provide an alternative link

Re: FLS Driver Support for Micron MT35XU01GBBA on S32G399

Hi Quang,

Unfortunately, we do not have a configuration example for enabling the MT35XU01GBBA memory in the FLS module through EB tresos for an AUTOSAR project. We confirmed that this device has not been tested, and the available RTD FIs demo only provides the configuration for the MX25UW51245G on the RDB board.

For clarity, the internal U-Boot/Linux discussion was focused on evaluating general BSP support for the same flash device and investigating a flash-probing issue, including the JEDEC ID read at 200 MHz. It was not a reference implementation or configuration for the AUTOSAR FLS module in EB tresos.

Therefore, we are unable to provide a reference example for the MT35XU01GBBA at this time. Nevertheless, we encourage you to proceed with your development and integration based on the available device documentation and your current setup.

If you encounter any specific error or unexpected behavior during the implementation, please share the details and relevant logs or configuration information. We will be happy to help analyze the issue. If you need further assistance, please open a private support ticket so we can provide more focused support.

We apologize for the inconvenience and appreciate your understanding.

Best regards, Aldo