AM623: Issues found in FLS MCAL AM62x

Part Number: AM623

Summary

During integration of Fee/Fls on AM62x Cortex-R5 with W25Q32JW NOR flash, two issues were found in the TI FLS MCAL driver (McalExt_TS_T31DxM1I0R0).

Environment

• SOC: AM62x, Cortex-R5
• MCAL: McalExt_TS_T31DxM1I0R0
• Flash: Winbond W25Q32JW 

Issue 1: OSPI_flashExecCmd calls GetCounterValue/GetElapsedValue inside SuspendAllInterrupts

Description

OSPI_flashExecCmd() in Fls_Ospi.c calls GetCounterValue() and GetElapsedValue() (with FLS_OS_COUNTER_ID = Hw_Counter) while interrupts are disabled by SchM_Enter_Fls_FLS_EXCLUSIVE_AREA_0 (= SuspendAllInterrupts).

Per AUTOSAR OS specification, these APIs require interrupts to be enabled. When OsStatus=EXTENDED, the OS returns OS_E_INTDISABLE (error 0x2D) and the counter values remain 0, breaking the timeout mechanism.

Call Chain

processJobs() [Fls_Brd_Nor.c line 773]
  → SchM_Enter_Fls_FLS_EXCLUSIVE_AREA_0()    ← interrupts disabled
    → Fls_norWrite() / Fls_norErase()
      → OSPI_transfer()
        → OSPI_dac_xfer_mode_write()
          → OSPI_waitDeviceReady()
            → OSPI_getDeviceStatus()
              → OSPI_cmdRead()
                → OSPI_flashExecCmd()          ← calls GetCounterValue/GetElapsedValue here
  → SchM_Exit_Fls_FLS_EXCLUSIVE_AREA_0()     ← interrupts re-enabled

Observed Behavior

• GetCounterValue() returns OS_E_INTDISABLE (16) instead of E_OK
• startcount and elapsedcount remain 0
• The timeout condition (elapsedcount >= FLS_TIMEOUT_DURATION) never fires
• The do-while loop exits only because CSL_ospiIsIdle() eventually returns TRUE
• System recovers but the timeout protection is non-functional

Impact

• Low severity — system recovers because OSPI commands complete normally
• Timeout mechanism in OSPI_flashExecCmd is broken (provides no protection against hung OSPI)
• OS ErrorHook is called repeatedly during every flash operation (performance overhead)

Suggested Fix

Replace GetCounterValue/GetElapsedValue in OSPI_flashExecCmd() with a simple decrement counter (similar to the existing retry counter pattern already used in the same function), or move the counter calls outside the critical section scope.

Issue 2: Verify impact of reducing FlsNORPageSize below physical flash page size (256 → 8)

Description

We need to reduce FlsNORPageSize from 256 to 8 to match FeeVirtualPageSize=8 (required for Fee/NvM flash footprint reduction from 256KB to 128KB). NOR_PAGE_SIZE is used in multiple places in the Fls MCAL driver, including the OSPI controller hardware register DEV_SIZE_CONFIG_REG (BYTES_PER_DEVICE_PAGE field).

Request TI to confirm whether reducing FlsNORPageSize to a value smaller than the physical flash page size (256 bytes for W25Q32JW) causes any functional issues or side effects.

Questions for TI

1. Does the OSPI Cadence controller use BYTES_PER_DEVICE_PAGE for any internal logic in DAC write mode beyond page boundary splitting? Is setting it to 8 safe when the physical device page is 256?
2. Are there any other internal uses of NOR_PAGE_SIZE in the MCAL driver (library code not visible to us) that could be affected?
3. Is this configuration (FlsNORPageSize < physical page size) a supported/tested configuration by TI?

Our Analysis

With DAC enabled (current config):

• OSPI_dac_xfer_mode_write() writes 4 bytes at a time with OSPI_waitDeviceReady() polling after each 4-byte write. Since 4 < 8, the BYTES_PER_DEVICE_PAGE=8 setting should not cause additional page boundary splits.
• The indirect write path (NOR_PAGE_SIZE chunking) is not reached because dacEnable=TRUE.
• All Fee write addresses are 8-byte aligned, so Fls_Write validation passes.

We believe NOR_PAGE_SIZE=8 is safe with DAC enabled but would like TI confirmation before production deployment.