Accelerometer continuous sketch crashing

#1

nano_ble33_sense_accelerometer_continuous.ino is crashing on my Nano 33 BLE Sense.
I think it is having some issue in run_inference function call. The onboard orange LED is blinking 4 x slow, 4 x fast pattern which (after googling I found) is due to MbedOS crash. Can someone test it?

#2

@naveen did you modify the sketch?

#3

@janjongboom I just modified the part which reads the sensor values to include gyroscope readings.

In setup():

      // changed 3 to 6
       if (EI_CLASSIFIER_RAW_SAMPLES_PER_FRAME != 6) {
              ei_printf("ERR: EI_CLASSIFIER_RAW_SAMPLES_PER_FRAME should be 
                          equal to 6 (3 acc axes + 3 gyro axes)\n");
            return;
        }

In loop():

        // changed -3 to -6
        numpy::roll(buffer, EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE, -6); 
      
        // changed the index
        IMU.readAcceleration(
            buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 6],
            buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 5],
            buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 4]
        );

        IMU.readGyroscope(
            buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 3],
            buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 2],
            buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 1]
        );

        buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 6] *= CONVERT_G_TO_MS2;
        buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 5] *= CONVERT_G_TO_MS2;
        buffer[EI_CLASSIFIER_DSP_INPUT_FRAME_SIZE - 4] *= CONVERT_G_TO_MS2;
#4

@janjongboom I have done further investigation and I doubt it is related to the stack size limitation of the thread. The sketch uses the accelerometer + gyroscope inference_buffer which requires 6 (axes) * 200 (frame size) * 4 (float size) = 4800 bytes. What is the default stack size for a single thread in Mbed OS? If it is 4K bytes or less, it could be the reason for the crash.

#5

@naveen, default stack size is indeed 4096 bytes. Large problem on the Nano is that if it hardfaults it also crashes the USB stack so you can’t see any errors.

You can change the memory allocated to the thread via:

static rtos::Thread inference_thread(osPriorityLow, 8192);

Or just malloc the buffer.

#6

@janjongboom Thanks for confirming the stack size. I have increased the stack size in the Thread initialization as you have suggested and it works! :smiley:
By the way I have seen run_classifier_continuous in the audio (continuous) example but why are we using run_classifier in accelerometer (continuous) example? What is the difference between these two functions?

#7

It’s because for accelerometer data we need the full window to extract features but for audio data we can extract features for a slice of data (say 250ms.) then stitch it to the features from the previous slices (that’s what the run_classifier_continuous does). But this only applies to audio data.

#8

Hi, today I got a similar problem with the with Arduino ble and accelerometer_continuous . The example code downloaded without any chage probably crashed due few memory allocated to the thread. As result the Serial monitor wasn’t able to connect Arduino and also impossible reload the sketch . I’ve solved thanks to this post after have spent a lot of time to put the Arduino in a condition to be again accessible to flash the sketck from IDE ,solved reflashing the Edge Impulse firmware . Could be usefull add a comment line above the thread initialization in the code generated to allert of this issue or change directly the memory allocated in the sketch ! Tks.

#9

Hi @bob63 yeah we should allocate this in static RAM or on the heap instead. Will create a ticket .

#10

This has now been resolved. Just re-export the library and in the latest example the memory is now statically allocated.