NanoEdge AI Backing up and restoring the library knowledge

[ygh2048]

I want to use the STM32F407 to implement the NanoEdge AI Library for Anomaly Detection (AD) tasks.

The documentation mentions nanoedge.ai's method for backing up and restoring the library knowledge using the .ld file in a Linux environment. I want to know how to perform this backup operation in Keil.

[Julian E.]

Hello @ygh2048,

It seems that the equivalent of a .ld file in CubeIDE is a .sct (scatter file) in keil.

Let’s say in STM32CubeIDE you had something like this in your .ld script:

ldCopyEdit.myKnowledge (NOLOAD) :
{
    KEEP(*(.myKnowledge))
} >FLASH

In Keil’s scatter file, you can do the equivalent:

1. Open / Create your scatter file (e.g., stm32f4xx_flash.sct)
2. Add your flash region inside the LR_IROM1 load region:

sctCopyEditLR_IROM1 0x08000000 0x00100000  { ; load region (1MB flash)
  
  ER_IROM1 0x08000000 0x00080000  { ; main code section (512 KB)
    *.o (RESET, +First)
    *(InRoot$$Sections)
    .ANY (+RO)
  }

  RW_IRAM1 0x20000000 0x00020000  { ; RAM
    .ANY (+RW +ZI)
  }

  ;Add your custom flash knowledge section here
  ER_KNOWLEDGE 0x08080000 0x00010000 { ; 64 KB for knowledge
    *.o (.myKnowledge)   ; or whatever your section name is
  }
}

3. Use attribute in your C file to place variables there:
In your .c file:

cCopyEdit__attribute__((section(".myKnowledge"))) const uint8_t learned_data[] = { ... };

Keil will place learned_data[] into your custom ER_KNOWLEDGE region at address 0x08080000.

Have a good day

Julian

[ygh2048]

Hello, thank you for your previous answer—it was very helpful. Additionally, I would like to ask for further clarification about this issue.

I noticed that when using Keil, I can directly retrieve the address and size of the .neai variable from the generated .map file. If I use this address directly for backup purposes, would this achieve the same effect while avoiding involvement with the scatter file (.sct)? Does this approach have any potential flaws or oversights?

[Julian E. · Accepted solution]

If you're just experimenting, accessing the address via .map is fine.

But for production firmware, we would recommend to:

• Define the region in the scatter file.
• Use symbols for start/end (more portable and safer):

extern const uint8_t __start_myKnowledge__;
extern const uint8_t __end_myKnowledge__;

Then compute size at runtime:

size_t size = &__end_myKnowledge__ - &__start_myKnowledge__;

The risks of not using the Scatter File are:
1.Uncontrolled Placement

• Flash address may vary between builds
• No reserved space for future growth
• Can’t easily exclude from CRC or secure checks

2.Optimization & Linker Shifts

• Section may be optimized out if unused
• Address may shift with minor code changes

3.Risk of Overlap

• Other sections (e.g., .text) can grow into .neai, causing corruption

4.Upgrade & Maintenance Issues

• Inconsistent location complicates backups, OTA updates, and version management

So it depends on what you are doing.

Have a good day,

Julian