AM263P4-Q1: Regarding writing to a FLASH region with cache enabled

Hi Imaoka,

Just a heads up that TI will do their very best to get you an initial response here on the E2E forum within 24 hours of your original posting time. Hopefully this helps save some time in your thread posting without needing to designate a dedicated desired response date.

Hi Imaoka-san,

Thank you for the detailed follow-up questions. I'll address each of your points systematically.

Response to [1. RL2 Cache Write Behavior]

Correct. If you are not using RL2 (Remote L2 cache), then the RL2 write behavior does not apply to your system. The RL2 is a software-configurable feature that must be explicitly enabled. Each R5F core has an integrated RL2 controller that can reserve system memory from L2 SRAM for caching 1-16MB of target Flash space. If your application does not enable RL2 caching, you can disregard the RL2 write restrictions mentioned in my previous response.

Response to [2. ECCM (ECC Memory) Constraints]

Q1: Does "Cached" in SysConfig correspond to "Normal & Cached"?

Yes. When you configure a flash region as "Cached" in SysConfig, it typically maps to FSS Region 0 or Region 1, both of which support OTFA (encryption/authentication) and ECCM (ECC protection). The FSS memory regions are organized as follows:

- Region 0 (0x60000000 - 0x67FFFFFF): Supports OTFA + ECC
- Region 1 (0x80000000 - 0x87FFFFFF): Supports OTFA + ECC and Address Remap-ability (Boot Space)
- Region 3 (0x88000000 - 0x8FFFFFFF): NO OTFA + NO ECC (Bypass Region)

If your flash region is configured as "Cached," ECCM is enabled by default.

Q2: Does SDK version 09_02_00_56 support FLSOPSKD?

The AM263Px hardware includes a feature called "FOTA HW ENGINE" (Firmware Over-The-Air Hardware Engine) which may be related to FLSOPSKD. The FOTA HW ENGINE supports XIP reads while FOTA updates happen in the background, which is the hardware mechanism for concurrent XIP and flash updates.

To verify FLSOPSKD/FOTA support in SDK 09_02_00_56:
- Check the SDK release notes for "FOTA HW ENGINE" or "Flash Operation Scheduler"
- Look for Opti-Flash examples in the SDK (these should include FLC, RL2, RAT examples)
- Check for FOTA-related APIs in the SDK Flash driver documentation

However, based on your use case description (no XIP during flash update, reboot after update), FLSOPSKD is not necessary for your application.

Q3: Is there a way to dynamically disable ECCM (for example, disabling ECCM only during flash update mode)?

No, ECCM cannot be dynamically disabled at runtime. ECCM is configured per FSS memory region and is set up during system initialization. The FSS provides 4 regions that can be configured for ECCM, and this configuration is part of the FSS region setup.

However, you can access the same physical flash location through different memory regions. All FSS regions (0, 1, 3) map to the same physical location in flash. You can write to flash through Region 3 (Bypass Region) which has NO ECCM enabled. This is the recommended approach for flash updates.

Q4: What kind of issues occur if flash is updated while ECCM remains enabled?

Flash writes to ECCM-enabled regions have strict alignment requirements:

- Writes to ECCM regions must be 32-byte aligned and have size that is a 32-byte multiple
- An error interrupt will be issued if either of these conditions are not met
- The FSS does not support read-modify-write for ECCM regions
- Variable block sizes for ECCM are not supported (only 32-byte block size is supported)

If you ignore the error, the flash write may fail or produce corrupted data. The ECC protection expects data to be written with proper ECC codes, which cannot be computed inline during standard Flash_write() operations.

Response to [3. Cache Coherency After Modification]

Q: How to implement the bypass region method?

Use FSS Region 3 (Bypass Region) for flash writes, then reboot. Here is the recommended sequence for your use case:

// Calculate bypass address from cached address
#define FLASH_REGION0_BASE   0x60000000  // Cached region
#define FLASH_BYPASS_BASE    0x88000000  // Bypass region

// Convert cached address to bypass address
uint32_t cachedAddr = 0x60100000;  // Your target flash address
uint32_t bypassAddr = FLASH_BYPASS_BASE + (cachedAddr - FLASH_REGION0_BASE);
// Result: bypassAddr = 0x88100000

// Perform erase and write through bypass region
Flash_eraseSector(bypassAddr, sectorSize);
Flash_write(bypassAddr, dataBuffer, dataSize);

// Reboot after update
// Cache invalidation handled automatically by reboot

Key points:
1. All FSS regions map to the same physical flash location, so writing to 0x88100000 (Region 3) updates the same flash cells as 0x60100000 (Region 0)
2. Region 3 (Bypass) has NO ECCM, so you can perform standard Flash_eraseSector() and Flash_write() without 32-byte alignment constraints or ECC computation
3. No need to disable cache - you simply access flash through a different memory region that bypasses ECCM
4. Since you reboot after flash update, cache invalidation is automatically handled by the reboot

Response to [To help refine this recommendation]

Q1: Our application does not perform flash erase/write while executing code via XIP. Programs and data are in OCSRAM. After updating flash, we reboot.

Perfect. This is the ideal scenario and the simplest approach:

1. No XIP during flash update eliminates any risk of executing stale cached code
2. Update code in OCSRAM ensures all update operations run from RAM
3. Reboot after update automatically invalidates all caches

Recommended approach:
- Use FSS Region 3 (Bypass Region) addresses for Flash_eraseSector() and Flash_write()
- No need to call CacheP_disable()
- No need to manually invalidate cache (reboot handles this)

Q2: Flash region is configured as "Cached" in SysConfig. Is ECCM enabled?

Yes, ECCM is enabled for "Cached" regions. As explained earlier, "Cached" regions map to FSS Region 0 or Region 1, which both have ECCM enabled.

To verify in your system:
- Check which FSS region address range your SysConfig "Cached" setting maps to
- If it's 0x60000000-0x67FFFFFF (Region 0) or 0x80000000-0x87FFFFFF (Region 1), ECCM is enabled

Q3: What exactly does "bypass region configuration" refer to?

"Bypass region" refers to FSS Region 3:

- SoC Address Range: 0x88000000 - 0x8FFFFFFF
- Size: 128 MB
- Features: NO OTFA + NO ECC
- Description: External Memory Space - Bypass Region

Primary functions:
- Bypasses both ECC and OTFA processing
- Enables direct flash programming with pre-authenticated and ECCM-protected data
- Supports error correction (scrubbing) operations

Usage: Access the same physical flash through Region 3 addresses instead of Region 0/1 addresses during flash write/erase operations.

Q4: Is FLSOPSKD supported in SDK version 09_02_00_56? How to verify hardware support?

To verify FLSOPSKD/FOTA HW ENGINE support in SDK 09_02_00_56:
1. Check SDK release notes for "FOTA HW ENGINE" or "Flash Operation Scheduler"
2. Look for Opti-Flash examples in the SDK
3. Check for FOTA-related APIs in the SDK Flash driver documentation

The FOTA HW ENGINE is a hardware feature of the AM263Px FSS subsystem with internal 2KB program memory, 256-byte data memory, and generates FOTA completion and error interrupts. Check your device variant documentation to confirm FOTA HW ENGINE is present.

However, for your use case (no XIP during flash update, reboot after update), FLSOPSKD is NOT necessary. FLSOPSKD is designed for concurrent XIP reads and flash writes, which you explicitly stated you do not need.

Summary and Recommended Solution

Given your specific requirements (no XIP during flash update, update code runs from OCSRAM, reboot after flash update), I recommend the following approach:

Use FSS Region 3 (Bypass Region) for Flash Write/Erase Operations

This approach provides:
1. No need to disable cache (CacheP_disable() not required)
2. No ECCM constraints (Region 3 bypasses ECCM)
3. No 32-byte alignment requirements for writes
4. No need to manually invalidate cache (reboot handles it)
5. Simplest possible implementation
6. No dependency on FLSOPSKD (not needed for your use case)

Implementation Steps:
1. Calculate the bypass region address by adding the offset from your cached address to the bypass base (0x88000000)
2. Use the bypass address in Flash_eraseSector() and Flash_write() calls
3. Reboot after flash update completes

To answer your original question directly: Yes, it is safe to erase and write to the FLASH area using Flash_eraseSector() and Flash_write() with cache enabled, provided you access flash through FSS Region 3 (Bypass Region) addresses. You do NOT need to call CacheP_disable() before flash operations when using the bypass region approach.

Please let me know if you need any clarification or have additional questions.

Best Regards,
Zackary Fleenor

Hi Imaoka-san,

Thank you for your follow-up questions. I'll address each point systematically.

Regarding Cache Coherency for Flash Verification

You are correct to be concerned about cache coherency when verifying flash written through Region 3 but reading from Region 0. Since all FSS regions map to the same physical flash location, the cache may contain stale data from Region 0 after writing through Region 3.

You have two valid options for verification:

Option A: Use CacheP_disable() and CacheP_enable()

// After flash write via Region 3
CacheP_disable(CacheP_TYPE_ALL);

// Perform verification by reading from Region 0 (cached region)
// Your verification code here

CacheP_enable(CacheP_TYPE_ALL);

This approach ensures no stale cached data interferes with verification. Since you are not using XIP during flash update, temporarily disabling cache has no performance impact.

Option B: Perform verification through Region 3

// Write to Region 3
Flash_write(bypassAddress, data, length);

// Verify by reading from Region 3 (same region)
verify_status = memcmp((void*)bypassAddress, data, length);

This approach avoids cache coherency issues entirely by reading directly from flash without cache interaction.

Both approaches are valid. Option A follows your preference to limit Region 3 usage to flash updates only. Option B is technically simpler since it avoids cache manipulation entirely. I recommend Option A based on your stated preference.

Regarding MPU Configuration for Region 3

Yes, your understanding is correct. FSS Region 3 (0x88000000 - 0x8FFFFFFF) should be configured as "Non-Cached" in SysConfig MPU settings.

Correct SysConfig MPU Configuration:

• Region: 0x88000000 - 0x8FFFFFFF
• Region Attributes: Non-Cached
• Access Permissions: Read/Write (as needed)

This configuration ensures direct hardware access to flash and proper bypass of ECCM and OTFA processing.

Regarding Address Calculation for FSS Region 3

Your address calculation formula contains a small error. You referenced FSS Region 1 base address as 0x60000000, but Region 1 is actually at 0x80000000. Region 0 is at 0x60000000.

The FSS region mapping is:

• Region 0: 0x60000000 - 0x67FFFFFF (OTFA + ECC, Cached)
• Region 1: 0x80000000 - 0x87FFFFFF (OTFA + ECC + Boot Remap, Cached)
• Region 3: 0x88000000 - 0x8FFFFFFF (NO OTFA + NO ECC, Bypass)

Correct Address Calculation:

If your cached flash region uses Region 0:

Bypass Address = Cached Address - 0x60000000 + 0x88000000

If your cached flash region uses Region 1:

Example for Region 0:

// 1. Calculate bypass address from your cached address
uint32_t cachedFlashAddr = 0x60100000;  // Your Region 0 cached address
uint32_t bypassFlashAddr = cachedFlashAddr - 0x60000000 + 0x88000000;

// 2. Erase flash sector via Region 3 (bypass)
Flash_eraseSector(bypassFlashAddr);

// 3. Write flash via Region 3 (bypass)
Flash_write(bypassFlashAddr, dataBuffer, dataLength);

// 4. Verify flash contents (Option A - your preferred approach)
CacheP_disable(CacheP_TYPE_ALL);
int verifyResult = memcmp((void*)cachedFlashAddr, dataBuffer, dataLength);
CacheP_enable(CacheP_TYPE_ALL);

// 5. Reboot system (cache automatically invalidated)
System_reset();

The key point from the technical documentation is that all FSS Regions (0, 1, 3) map to the same physical location in flash. The upper 5 address bits [31:27] differentiate the regions, but the lower 27 bits [26:0] point to the same physical flash location.

Complete Implementation Summary

Based on your requirements, here is the complete recommended sequence:

// 1. Calculate bypass address from your cached address
uint32_t cachedFlashAddr = 0x60100000;  // Your Region 0 cached address
uint32_t bypassFlashAddr = cachedFlashAddr - 0x60000000 + 0x88000000;

// 2. Erase flash sector via Region 3 (bypass)
Flash_eraseSector(bypassFlashAddr);

// 3. Write flash via Region 3 (bypass)
Flash_write(bypassFlashAddr, dataBuffer, dataLength);

// 4. Verify flash contents (Option A - your preferred approach)
CacheP_disable(CacheP_TYPE_ALL);
int verifyResult = memcmp((void*)cachedFlashAddr, dataBuffer, dataLength);
CacheP_enable(CacheP_TYPE_ALL);

// 5. Reboot system (cache automatically invalidated)
System_reset();

This approach provides:

• No ECCM constraints during flash write/erase
• Simple cache coherency handling for verification
• No dependency on FLSOPSKD
• Clean separation between flash update operations and normal cached access

Please verify which FSS region your SysConfig "Cached" setting maps to (Region 0 at 0x60000000 or Region 1 at 0x80000000) and use the corresponding address calculation formula.

Let me know if you need any additional clarification.

Best Regards,
Zackary Fleenor

Hi Imaoka-san,

Thank you for clarifying that you'll proceed with Option B (verification through Region 3).

Regarding your question about accessing FSS Region 3 using the Flash APIs that accept offset parameters, here is the guidance:

Understanding Flash API Offset Handling

The Flash APIs you listed use offset-based addressing relative to a base address configured in the Flash driver instance. The key is understanding which base address your Flash driver instance is configured to use.

Recommended Approach: Use Separate Flash Driver Instances

Configure two Flash driver instances in SysConfig:

1. Instance 0 (Cached Region 0):

   • Base Address: 0x60000000 (FSS Region 0)
   • Region Attributes: Cached
   • Use for: Normal read operations

2. Instance 1 (Bypass Region 3):

   • Base Address: 0x88000000 (FSS Region 3)
   • Region Attributes: Non-Cached
   • Use for: Flash write/erase/verify operations

Implementation Example:

// Open two Flash driver instances
Flash_Handle flashHandleCached = Flash_open(CONFIG_FLASH0, NULL);  // Region 0
Flash_Handle flashHandleBypass = Flash_open(CONFIG_FLASH1, NULL);  // Region 3

// Write to flash using Region 3 (Bypass)
uint32_t offset = 0x00100000;  // Offset within flash
Flash_eraseSector(flashHandleBypass, sectorNum);
Flash_write(flashHandleBypass, offset, writeBuffer, writeLen);

// Verify through Region 3 (Bypass) - no cache coherency issues
Flash_read(flashHandleBypass, offset, verifyBuffer, writeLen);

// Compare
if (memcmp(writeBuffer, verifyBuffer, writeLen) == 0) {
    // Verification passed
}

// After reboot, normal operations use Region 0 (Cached)
Flash_read(flashHandleCached, offset, readBuffer, readLen);

Key Points About Flash API Offset Addressing

1. The Flash APIs internally calculate: Absolute Address = flashBaseAddr + offset

2. Use Flash_getAttrs() to retrieve the base address configured for your Flash instance:

   Flash_Attrs *attrs = Flash_getAttrs(CONFIG_FLASH0);
   uint32_t baseAddr = attrs->flashBaseAddr;  // e.g., 0x60000000

3. To access Region 3 with offset-based APIs, you need a Flash driver instance configured with flashBaseAddr = 0x88000000

4. The offset remains the same across regions since all regions map to the same physical flash location. Only the base address changes.

SysConfig Configuration Steps

1. In SysConfig, add a second Flash instance:

   • Name: CONFIG_FLASH_BYPASS (or similar)
   • Flash Base Address: 0x88000000
   • Region Attributes: Non-Cached
   • Size: Match your flash size

2. In your flash update code:

   // Open bypass region handle for update operations
   Flash_Handle bypassHandle = Flash_open(CONFIG_FLASH_BYPASS, NULL);
   
   // Perform erase/write/verify through Region 3
   Flash_eraseSector(bypassHandle, sectorNum);
   Flash_write(bypassHandle, offset, writeBuffer, writeLen);
   Flash_read(bypassHandle, offset, verifyBuffer, writeLen);
   
   // Verification
   if (memcmp(writeBuffer, verifyBuffer, writeLen) == 0) {
       // Success
   }
   
   Flash_close(bypassHandle);

3. After reboot, your normal application uses the cached Region 0 instance.

Alternative Approach: Direct Memory Access for Verification

If you cannot configure a separate Flash driver instance for Region 3, you can calculate the absolute Region 3 address and perform direct memory reads for verification:

Flash_Handle flashHandle = Flash_open(CONFIG_FLASH0, NULL);
Flash_Attrs *attrs = Flash_getAttrs(CONFIG_FLASH0);

uint32_t cachedBaseAddr = attrs->flashBaseAddr;  // 0x60000000 or 0x80000000
uint32_t bypassBaseAddr = 0x88000000;
uint32_t offset = 0x00100000;

// Calculate absolute bypass address
uint32_t bypassAddr = bypassBaseAddr + offset;

// Write using Flash API
Flash_eraseSector(flashHandle, sectorNum);
Flash_write(flashHandle, offset, writeBuffer, writeLen);

// Verify by reading directly from Region 3 bypass address
uint8_t *bypassPtr = (uint8_t *)bypassAddr;
if (memcmp(writeBuffer, bypassPtr, writeLen) == 0) {
    // Verification passed
}

Summary

The recommended solution is to configure a second Flash driver instance in SysConfig with base address 0x88000000 (Region 3, Non-Cached). Use the bypass handle for all flash update operations (erase/write/verify). The same offset values work across both instances since they map to the same physical flash. This approach eliminates cache coherency issues when verifying through Region 3.

Please let me know if you need clarification on the SysConfig configuration or have any additional questions.

Best Regards,
Zackary Fleenor