Audio classifier fails to run on st-b-l475e-iot01a

Report bugs
#1

Project ID

Conditions

  • Latest firmware downloaded to board
  • Successful model generation

Issue
Classifier fails to run with output below

AT+RUNIMPULSEDEBUG

Inferencing settings:
	Interval: 0.06 ms.
	Frame size: 32000
	Sample length: 2000 ms.
	No. of classes: 4
Starting inferencing, press 'b' to break
Starting inferencing in 2 seconds...
Recording
Recording OK
ERR: cmvnw failed (-1002)
ERR: Failed to run DSP process (-1002)
ERR: Failed to run classifier (-5)
#2

Hi @mcallistertad This is an out of memory error when running the model. You can up the frame length / frame stride a bit in your DSP block to make it use less memory.

3 Likes
#3

Hi @janjongboom,

I’m getting the same error but I’m not running an audio DSP.
Is there any similar trick to lower memory usage in Spectral Analysis and/or Flatten?

Thanks,
Spiros

#4

@SpirosMakris Typically flatten / spectral analysis blocks use a lot less RAM, so should be less of an issue on this board. Which of your projects does this refer to?

1 Like
#5

Hi @janjongboom!

I though it was a RAM issue, but I’m not so sure now.

I had multiple DSP blocks (1 spectral, 2 flatten) and no matter how I configured them I got the “out of ram” ERR: DSP (-5)/Classifier(-1002) message on the board (I thing these are the error numbers). Although I’m pretty sure there’s like 150k of free RAM left on the ESP.

When I remove the extra DSPs and fed all of my features through a single spectral DSP it runs, but I’m not so sure that feeding 3 different sensor readings in to a single DSP is good for accuracy.

Any thoughts?
The project is: https://studio.edgeimpulse.com/studio/31046

Thanks,
Spiros

#6

@SpirosMakris Ah, yeah, this is a bug that pops up sometimes. There are issues with feeding some axis into one DSP block, and other axis into another. We have a tracking bug for it, but can’t provide a date for this to be fixed yet.

I think just feeding into the single DSP block should be fine for now.

#7

Thanks @janjongboom !
I understand. That’s what I did in the end.
Hoping this will be fixed soon.

Cheers!

1 Like
#8

Thanks @janjongboom. Adjusting the frame length/ stride did the job and it’s running on the hardware now.

#9

As an aside, is there a method for predicting memory usage before the binary is generated for the target hardware? A warning or something would be useful.

#10

Yeah we have all that data already available in the backend, but we don’t expose it yet. Good suggestion.

1 Like
#11

@SpirosMakris We have a patch ready, hope to release this next week (anything that touches core DSP code requires some extensive testing on device :slight_smile: ).

2 Likes
#12

Hey @janjongboom, glad to hear this is being fixed. Is there anyplace I could look for status updates on this, like a github issue or a log?

Thanks,
Spiros

#13

Hi, our GH issues are not public unfortunately, but I’ll update this forum post once released - we’re investigating flash size increase on one of our targets with the patch.

1 Like
#14

Thanks @janjongboom! I’ll keep an eye on this!

Cheers,
Spiros

#15

This has now been resolved!

1 Like
#16

Thanks for the update @janjongboom!

1 Like