AI Runner communication and strange effect on target

[mch_hm]

Hello,

I’have managed to define/train/quantize/translate_for_target a model so far. The target is the STM32N6.

I have also managed to run the model on the target by an own script using airunner functions/methods.

The last step remaining is to get rid of the airunner-magic so that i can integrate the created .c/.h (by stedgeai) into my own framework on the target. 

Observation 1:

I first noticed that the memory location of the weights is neither az 0x7100_0000 nor at 0x7038_0000 as suggested by the output.

From network_generate_report.txt:

octoFlash  [0x70380000 - 0x71380000]:     60.095 kB /     16.000 MB  (  0.37 % used) -- weights:     60.095 kB

From the generated C-File network_atonbuf.xSPI2.c (as a comment):

/* index=8 file postfix=xSPI2 name=octoFlash offset=0x71000000 …. */

LL_ATON_ALIGNED(64) const uint64_t _mem_pool_xSPI2_network[7693] = {

It finally ended up at 0x701253c0. I have a hard time underrstanding which tool is relocating the buffers from where it is initially supposed to live. Is there any description of the process from start (*.mpool) to end (actual location on the target)? There was a recent post from that uncovered a linker script glitch which probably explains my current unexpected location but the overall process is stillin my opinion not well documented. Or I did not find the proper docs.

Observation 2:

The second problem is that the AI Runner package goes into some sort of debug mode where it prints a lot of information about each transfer it does. This can be seen in the screen shot “airunner debug output.png”. Only the very first run does not produce this output. I have to reload the module/kernel to get one next run without that output.

The disctracting output does not affect the functionality - the communication succeeds. What can I do programmatically to suppress that output?

Observation 3:

After I have transferred an input vector via AI Runner to the target the input buffer is filled up as expected (see input after upload.png). However, after I fetched the result from the output buffer a small part at the beginning of the input buffer is destroyed (see destroyed input.png). The input buffer extends up to 0x43f, so this is in a area where no changes should happen.

Who is responsible for that effect? Is it something in the AI support firmware on the target?

Best rergards,

Mike

(HW: STM32N6 DK and Nucleo, SW: stdedge 4.0.1, Cube 2.2.0)

 

 

 

 

[hamitiya]

Hello ​@mch_hm 

Indeed, if you are working with C file, it could be decided during linkage. You can either create a section in your linker script dedicated to these weights in order to have it at the address 0x7100_0000, or you can export weights as binary. 

Open “Memory Pools” > “Weights Mapping”

For the distracting logs, it should be printed only in debug mode. Could you confirm in your environment variables, DEBUG is not defined ?

 

Best regards,

Yanis

[mch_hm]

Thanks for the suggestion about an environment change!

I’ll check that. It’s strange that the first run of the python script runs in “normal” mode. I do change intentionally anything before the second run.

 

For the memory allocation:

I did find a rather promising documentation shortly after my post. It is “stneuralart_memory_initializers.html”. I think this answers my own complaint about “Or I did not find the proper docs.”.

The unexpected memory allocation may be due to a linker script glitch as described by Mr. Zahimi 6 days ago. The weights probably ended up in rodata by default. I should be able to get that straight in my project. 

Best regards, Mike