• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 33 subscribers
  • Views 95 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2612: Issue regarding AM2612 protocol stack and Flash memory usage Problem

Leo Wu
Intellectual 2170 points

Part Number: AM2612
Other Parts Discussed in Thread: SYSCONFIG

Hi experts,

When using the protocol stack for the AM2612, our customer discovered a bug that affects program execution when the 4MB area preceding the Flash is being erased. However, the actual program is only programmed within the first 3MB.
Specific Questions:
  1. What content is intended to run in the remaining space before the 4MB mark?
  2. What is the minimum required size for this space?
  3. Is it possible to change the memory location being used, and if so, how can this configuration be modified?

Thanks

  • 0
    TI__Mastermind 40453 points
    Hi Leo,
    Thanks for the details. Here's what we can confirm from documentation and related AM2612 threads, along with what still needs clarification from the customer.
    We don't have a documented case that specifically ties a "4MB area before Flash erase" to a protocol-stack bug on AM2612. What we do have is relevant hardware/memory-map context below that likely explains the behavior — but to pin down the exact root cause we'll need a bit more info from the customer (see the follow-up question at the end).
    1. What's intended to occupy the space between the 3MB program and the 4MB boundary?
    This depends heavily on whether the flash is attached via GPMC or OSPI:
    • If GPMC: The AM2612 GPMC interface supports address/data-non-multiplexed memories with an address range of 4MB, and the datasheet confirms GPMC provides "Up to 4MB addressable memory space." If your customer's flash sits on GPMC, the "4MB area" may simply be the full addressable GPMC window — meaning the space beyond the 3MB program isn't necessarily reserved for specific content; it's just unused/unmapped address range within that fixed 4MB window.
    • If OSPI with ECCM/Authentication enabled: A fixed percentage of the flash is reserved for ECC/MAC data regardless of whether it's actually used — 11% if only ECCM or only Authentication is enabled, and 20% if both are enabled (4-byte MAC). This reserved region backs the ECC/authentication data structures and isn't something that can simply be erased without breaking ECC/auth integrity. However, note this doesn't map cleanly to a 1MB/4MB (25%) split, so it's worth confirming this is even in play for your case.
    • Protocol stack footprint context: Via XIP, PROFINET uses ~941KB flash + 1.08MB RAM, EtherCAT uses ~193KB flash + 115KB RAM, and EtherNet/IP uses ~333.71KB flash + 564KB RAM. None of these individually or combined account for a full 3–4MB flash footprint, so the "4MB" boundary is more likely a fixed memory-map/addressing artifact (GPMC window or OSPI FSS region sizing) than actual protocol stack code.
    2. What is the minimum required size for this space?
    If it's a GPMC addressing artifact, there's no "minimum size" requirement for the extra 1MB — it's simply unused address space, not a hard requirement. If ECCM/Authentication is enabled on OSPI, the minimum reserved amount is fixed by the percentage above (11% or 20% of total flash) and can't be shrunk below that while ECC/auth remains enabled.
    3. Can the memory location be changed, and how?
    Yes — flash memory regions, load addresses, and run addresses are fully configurable via the SysConfig Memory Configurator in the MCU+ SDK. Specifically, you can:
    • Add or resize memory regions (must be power-of-2 sized, with base address aligned to size)
    • Redirect a linker section's load/run memory to a different named region, or specify an explicit load/run address
    • Split a section across multiple memory regions by priority order
    This is done by editing the FLASH memory region definition and the relevant output section's "Load Memory"/"Run Memory" (or explicit Load/Run Address) fields in the Memory Configurator — SysConfig regenerates linker.cmd accordingly.
    Related troubleshooting note: A separate AM2612 E2E thread (AM2612 Flasher Cannot Erase Flash on Cust PCB) found that flash-erase failures tied to SBL/bootloader state (not an address-map issue) were resolved by either using SBL NULL / dev boot mode for LOAD PROGRAM operations, or by setting a flag to keep the system in SBL after re-power to allow repeated erase/load cycles. If your customer's erase issue turns out to be boot-state related rather than purely an address-map/reserved-region issue, this troubleshooting path may also be relevant.
    Follow-up question: Could you confirm with the customer whether the flash is connected via GPMC or OSPI, and whether ECCM/Authentication is enabled in their SysConfig flash settings? That will tell us definitively whether the extra ~1MB is a GPMC addressing-window artifact or a reserved ECC/authentication region — and from there we can advise on the exact minimum safe size and erase boundaries.
    Best Regards,
    Zackary Fleenor