Unaligned memory access

Help
#1

Hi,

I’am trying to run this sample GitHub - edgeimpulse/example-standalone-inferencing-zephyr with my model on an nrf9160 based board.

It crashes after the features are generated. How could this be resolved ?

17:05:56.556 -> Edge Impulse standalone inferencing number 2 (Zephyr)
17:05:56.556 -> Features (1 ms.): -66.589996 -277.000000 57.000000 105.712395 82.102898 -0.766364 -0.002599 8.810000 -130.000000 237.000000 84.623581 84.163727 0.640647 0.242610 -155.789993 -433.000000 33.000000 198.264694 122.631004 -0.042173 -0.980243 

17:05:56.556 -> [00:00:00.500,152] e[0m<inf> actinius_board_control: External SIM is selectede[0m
17:05:56.556 -> [00:00:00.532,287] e[1;31m<err> os: ***** USAGE FAULT *****e[0m
17:05:56.556 -> [00:00:00.532,287] e[1;31m<err> os:   Unaligned memory accesse[0m
17:05:56.556 -> [00:00:00.532,318] e[1;31m<err> os: r0/a1:  0x00000001  r1/a2:  0x2000d0b8  r2/a3:  0xb4002012e[0m
17:05:56.556 -> [00:00:00.532,348] e[1;31m<err> os: r3/a4:  0xb4002012 r12/ip:  0x0000000a r14/lr:  0x0000d353e[0m
17:05:56.556 -> [00:00:00.532,348] e[1;31m<err> os:  xpsr:  0x81000000e[0m
17:05:56.556 -> [00:00:00.532,379] e[1;31m<err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000e[0m
17:05:56.556 -> [00:00:00.532,409] e[1;31m<err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000e[0m
17:05:56.556 -> [00:00:00.532,409] e[1;31m<err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000e[0m
17:05:56.556 -> [00:00:00.532,440] e[1;31m<err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000e[0m
17:05:56.556 -> [00:00:00.532,470] e[1;31m<err> os: fpscr:  0x200111b8e[0m
17:05:56.556 -> [00:00:00.532,501] e[1;31m<err> os: Faulting instruction address (r15/pc): 0x0000d346e[0m
17:05:56.556 -> [00:00:00.532,531] e[1;31m<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0e[0m
17:05:56.556 -> [00:00:00.532,562] e[1;31m<err> os: Current thread: 0x2000d0b8 (unknown)e[0m
17:05:56.556 -> [00:00:00.643,371] e[1;31m<err> fatal_error: Resetting systeme[0m
�*** Booting Zephyr OS build v3.2.99-ncs1 ***
17:05:
#2

The debug statements were responsible for the crash, with debug switched of it runs fine.

1 Like
#3

Hi @sebastiaan

Can you please send information what did you change regarding debug and what board did you use (I assume nrf9160dk) so I can reproduce the issue.

Also the log you sent in original post, is that on UART on RTT?

Thanks!

Vojislav

#4

Hi @vojislav

I just changed

EI_IMPULSE_ERROR res = run_classifier(&features_signal, &result, true);
to
EI_IMPULSE_ERROR res = run_classifier(&features_signal, &result, false);

I reproduced the same behaviour with the desktop example GitHub - edgeimpulse/example-standalone-inferencing: Builds and runs an exported impulse locally (C++)

So i guess it has something to do with the model and data. You can find the complete project here;

#5

Hi @sebastiaan !
I checked your example-standalone and was NOT able to reproduce the issue after restoring the Makefile to it’s original state (same as in Makefile_bak) - otherwise I am not able to compile on Mac.

Features (0 ms.): -37.689999 -156.000000 78.000000 65.494957 53.563538 -0.237269 -0.849599 39.560001 -85.000000 388.000000 108.275024 100.789330 1.816077 2.966246 -51.200001 -241.000000 226.000000 117.109093 105.323860 0.180753 -0.369365 
Running impulse...
Predictions (time: 0 ms.):
value:  562.707092
Anomaly score (time: 0 ms.): -0.450819
run_classifier returned: 0
Timing: DSP 0 ms, inference 0 ms, anomaly 0 ms
Predictions:
  value: 562.70709
Anomaly prediction: -0.451

The inference is run correctly with and without debug prints.
@vojislav let us know if you can reproduce on Nordic.

#6

Yea, we where able to reproduce on Nordic board, and are looking into the solution.

#7

Hi @AIWintermuteAI

Can someone reproduce on windows ? I get

Features (0 ms.): -37.689999 -156.000000 78.000000 65.494957 53.563538 -0.237269 -0.849599 39.560001 -85.000000 388.000000 108.275024 100.789330 1.816077 2.966246 -51.200001 -241.000000 226.000000 117.109093 105.323860 0.180753 -0.369365

#8

Hi @sebastiaan
We found the issue and the fix should land soon in the production (probably tomorrow or day after). Will let you know.

Cheers,
Vojislav

#9

The fix is in production so it should be resolved.