• State
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 81 views
  • Users 0 members are here
Support feedback
Options
Options
Related

RM57L843: Fapi_doBlankCheckByByte

Filip
Prodigy 20 points
Part Number: RM57L843

Tool/software:

I don't understand what is a valid way to use Fapi_doBlankCheckByByte() function.

My understanding is that this function enables me safe read if flash location is empty or not. In runtime we want to write some logs and for that we have to determine first empty address. We plan to use Sectors 14 and 15 of Bank 1.

Description of the function says "As the erase state of the Flash is not a valid ECC condition, on Banks 0 - 6 ECC correction at a minimum must be disabled." and I don't know how to do that or is it even possible as we can't disable ECC on this CPU.
Linker file is set to calculate ECC for all other addresses during load, whole flash is 32 bytes aligned so cache doesn't trigger ECC error and ESM Stat2 register is empty, up until we use Fapi_doBlankCheckByByte() function.
Also I have attempted l2ramwREG->RAMCTRL = 0x05050005U; before call of the function.
If you can tell me what I misunderstood about usage of Fapi_doBlankCheckByByte and if possible provide steps how to correctly read empty location during runtime.
BR,
Filip

  • 0
    TI__Guru 70681 points

    Hi Filip,

    I got some useful information and suggestions from our TI internal AI tool for this question, i hope this would be very useful for this case. So please look into this information once and let me know if you need further help on this issue:

    1. Understanding the Issue:
    • The main challenge is that reading erased flash locations triggers ECC errors because erased state (0xFF) is not a valid ECC condition (1)
    • Simply disabling ECC is not possible on RM57L843 as it's a safety feature (1, 2)
    • The l2ramwREG->RAMCTRL setting you tried doesn't affect flash ECC handling (2)
    1. Correct Approach for Flash Operations:

    Instead of using Fapi_doBlankCheckByByte(), here's the recommended approach for runtime flash operations:

    a) For Finding Empty Location:

    // 1. Use a header structure at the beginning of each log entry
typedef struct {
    uint32_t validityFlag;  // e.g., 0xFFFFFFFF = empty, 0x12345678 = valid
    uint32_t length;
    // ... other header information
} LogHeader;

// 2. Read the header structure instead of checking for blank space
LogHeader header;

    b) Proper Flash Writing Sequence:

    // 1. Initialize Flash API
Fapi_StatusType status;
Fapi_initializeFlashBanks(DEVICE_FREQUENCY);

// 2. Configure Flash state machine
Flash_setEEERASEMode();
Flash_setEWAITValue(2);

// 3. Find next write location by reading headers
// This won't trigger ECC errors since you're reading valid data structures

// 4. Before writing, ensure sector is erased if needed
Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,
                                 (uint32_t)sector_start_address);

// 5. Write data with proper ECC calculation
status = Fapi_issueProgrammingCommand((uint32_t*)write_address,
                                    (uint32_t*)data_buffer,
                                    count,
                                    0,
                                    0,
                                    Fapi_AutoEccGeneration);

    E2E MAGENT
    Today at 12:16 PM

    I'll help you understand the proper usage of Fapi_doBlankCheckByByte() and flash memory handling on the RM57L843. Let me search through the available resources to provide comprehensive information.

    First, let's search for specific information about Fapi_doBlankCheckByByte:

    Collapse
    Run
    SaveCopy
    1
    2
    3
    4
    5
    Calling tool: search_e2e_database
    -devices: ['RM57L843']
    -question: How to properly use Fapi_doBlankCheckByByte function and handle ECC for flash blank check
    -lexical_interpolation: 0.005

    Let me try another search focusing on flash operations and ECC:

    Collapse
    SaveCopy
    1
    2
    3
    4
    5
    Calling tool: search_e2e_database
    -devices: ['RM57L843']
    -question: Flash blank check ECC handling runtime flash write sectors 14 15 bank 1
    -lexical_interpolation: 0.05

    Let me do one more search specifically about runtime flash operations:

    Collapse
    SaveCopy
    1
    2
    3
    4
    5
    Calling tool: search_veloce_documents
    -devices: ['RM57L843']
    -question: Runtime flash write operations blank check ECC handling
    -lexical_interpolation: 0.01

    Based on the search results and TI documentation, I can provide a detailed explanation about the proper usage of Fapi_doBlankCheckByByte() and flash handling. Here's the comprehensive answer:

    1. Understanding the Issue:
    • The main challenge is that reading erased flash locations triggers ECC errors because erased state (0xFF) is not a valid ECC condition (1)
    • Simply disabling ECC is not possible on RM57L843 as it's a safety feature (1, 2)
    • The l2ramwREG->RAMCTRL setting you tried doesn't affect flash ECC handling (2)
    1. Correct Approach for Flash Operations:

    Instead of using Fapi_doBlankCheckByByte(), here's the recommended approach for runtime flash operations:

    a) For Finding Empty Location:

    c
    Collapse
    SaveCopy
    1
    2
    3
    4
    5
    6
    7
    8
    9
    ⌄
    // 1. Use a header structure at the beginning of each log entry
    typedef struct {
    uint32_t validityFlag; // e.g., 0xFFFFFFFF = empty, 0x12345678 = valid
    uint32_t length;
    // ... other header information
    } LogHeader;
    // 2. Read the header structure instead of checking for blank space
    LogHeader header;

    b) Proper Flash Writing Sequence:

    c
    Collapse
    SaveCopy
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    // 1. Initialize Flash API
    Fapi_StatusType status;
    Fapi_initializeFlashBanks(DEVICE_FREQUENCY);
    // 2. Configure Flash state machine
    Flash_setEEERASEMode();
    Flash_setEWAITValue(2);
    // 3. Find next write location by reading headers
    // This won't trigger ECC errors since you're reading valid data structures
    // 4. Before writing, ensure sector is erased if needed
    Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,
    (uint32_t)sector_start_address);
    // 5. Write data with proper ECC calculation
    status = Fapi_issueProgrammingCommand((uint32_t*)write_address,
    (uint32_t*)data_buffer,
    count,
    0,
    0,
    Fapi_AutoEccGeneration);
    1. Key Points for Implementation:

    a) Flash Organization:

    • Use structured data format with headers (3)
    • Always align data to 32-byte boundaries (1)
    • Keep track of the last written position using headers rather than searching for blank space

    b) Error Handling:

    • Implement proper error handling for Flash API operations
    • Monitor Flash API status returns
    • Handle any ECC errors that might occur during normal operations

    1. Best Practices:

    2. Data Structure:

    #define VALID_ENTRY_MARKER 0x12345678
#define EMPTY_MARKER      0xFFFFFFFF

typedef struct {
    uint32_t marker;          // Used to identify valid/empty entries
    uint32_t sequence;        // Optional: for tracking write order
    uint32_t length;          // Length of actual data
    uint32_t checksum;        // Optional: additional data validation
    // ... actual data follows
} LogEntryHeader;

     Finding Empty Space:

    LogEntryHeader* findNextWriteLocation(uint32_t sectorStart, uint32_t sectorEnd) {
    LogEntryHeader* current = (LogEntryHeader*)sectorStart;
    
    while ((uint32_t)current < sectorEnd) {
        if (current->marker == EMPTY_MARKER) {
            return current;
        }
        current = (LogEntryHeader*)((uint32_t)current + 
                  ALIGN_32(sizeof(LogEntryHeader) + current->length));
    }
    return NULL; // Sector is full
}

    1. Important Considerations:

    2. Always use proper alignment (32-byte) for flash operations

    3. Implement wear-leveling if frequent writes are expected

    4. Consider implementing a circular buffer mechanism for logs

    5. Keep backup of critical data before erasing sectors

    6. Validate data after writing using checksums or CRC

    --
    Thanks & regards,
    Jagadish.

  • 0
    Prodigy 20 points

    Thank you for your reply jagadish.

    1. I understand, this was desperate attempt to try something. 
      jagadish gundavarapu said:
      The l2ramwREG->RAMCTRL setting you tried doesn't affect flash ECC handling (2)
    2. I can't find any reference to functions mentioned here. 
      jagadish gundavarapu said:
      Flash_setEEERASEMode();
      Flash_setEWAITValue(2);
      So if you could please explain me what I would need to do. From looking into FSM commands I can't figure out what are specific steps.
    3. Just to confirm than Fapi_doBlankCheck() and Fapi_doBlankCheckByByte(), are probably not advised to be used in runtime but probably just diagnostic functions?