espressif / arduino-esp32

Arduino core for the ESP32
GNU Lesser General Public License v2.1
13.28k stars 7.35k forks source link

Rolling reboot #1307

Closed twinotter closed 5 years ago

twinotter commented 6 years ago

Hardware:

Board: ESP32 Dev Module C Core Installation/update date: 10/apr/2018 IDE name: Arduino IDE Flash Frequency: 80Mhz Upload Speed: 921600

I'm not sure where to begin debugging this problem. I'm trying to get SmartMatrix and FastLED working on an ESP32. Separately the components work, but when I combine together, I'm getting an assert that causes a rolling reboot before anything gets started. I'm guessing a memory problem, but I'm uncertain where.

Reboot:
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13076
entry 0x40078a58
assertion "res == pdTRUE" failed: file "/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./dport_access.c", line 187, function: esp_dport_access_int_init
abort() was called at PC 0x400d5173 on core 1

Backtrace: 0x40087538:0x3ffe7ce0 0x40087637:0x3ffe7d00 0x400d5173:0x3ffe7d20 0x400d61ce:0x3ffe7d50 0x40082750:0x3ffe7d80 0x40082791:0x3ffe7da0 0x40007c31:0x3ffe7dc0 0x4000073d:0x3ffe7e30

Rebooting...

Stack results:

Decoding stack results
0x40087538: invoke_abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 139
0x40087637: abort at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./panic.c line 148
0x400d5173: __assert_func at ../../../.././newlib/libc/stdlib/assert.c line 63
0x400d61ce: esp_dport_access_int_init at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./dport_access.c line 187
0x40082750: start_cpu1_default at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 385
0x40082791: call_start_cpu1 at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/./cpu_start.c line 235
twinotter commented 6 years ago

The problem appears to be an issue with how memory is allocated in compilation. Either commenting out some of the code in the setup() OR commenting out test2 will make this work. The code below demonstrates the problem. Issue #900 seems to have this same problem, but is unsolved.

I tried to simplify the code as much as possible and still capture the issue. I found at some point that things just suddenly worked. The code below causes the boot loop. But you can make the code work by either removing the "test2" String or commenting out the code in the setup() routine. (You can leave the Serial port initialization and sample write and still see it work successfully.)

The SmartMatrix library I'm using is here. The FastLED library is here. Otherwise, it's just the libraries included with esp32.

/*
 * This example shows how to display bitmaps that are exported from GIMP and
 * compiled into the sketch and stored in the Teensy's Flash memory
 * See more details here:
 * http://docs.pixelmatix.com/SmartMatrix/library.html#smartmatrix-library-how-to-use-the-library-drawing-raw-bitmaps
 *
 * This example uses only the SmartMatrix Background layer
 */

//#include <SmartLEDShieldV4.h>  // uncomment this line for SmartLED Shield V4 (needs to be before #include <SmartMatrix3.h>)
#include <SmartMatrix3.h>
#include <FastLED.h>

#define COLOR_DEPTH 24                  // known working: 24, 48 - If the sketch uses type `rgb24` directly, COLOR_DEPTH must be 24
const uint8_t kMatrixWidth = 64;        // known working: 16, 32, 48, 64
const uint8_t kMatrixHeight = 64;       // known working: 32, 64, 96, 128
const uint8_t kRefreshDepth = 24;       // known working: 24, 36, 48
const uint8_t kDmaBufferRows = 2;       // known working: 2-4, use 2 to save memory, more to keep from dropping frames and automatically lowering refresh rate
const uint8_t kPanelType = SMARTMATRIX_HUB75_64ROW_MOD32SCAN;   // use SMARTMATRIX_HUB75_16ROW_MOD8SCAN for common 16x32 panels
const uint8_t kMatrixOptions = (SMARTMATRIX_OPTIONS_NONE);      // see http://docs.pixelmatix.com/SmartMatrix for options
const uint8_t kBackgroundLayerOptions = (SM_BACKGROUND_OPTIONS_NONE);

SMARTMATRIX_ALLOCATE_BUFFERS(matrix, kMatrixWidth, kMatrixHeight, kRefreshDepth, kDmaBufferRows, kPanelType, kMatrixOptions);
SMARTMATRIX_ALLOCATE_BACKGROUND_LAYER(backgroundLayer, kMatrixWidth, kMatrixHeight, COLOR_DEPTH, kBackgroundLayerOptions);

String test1 = "test1";
String test2 = "test2";

void setup() {
    Serial.begin(115200);
  Serial.println("Hi!");

  matrix.addLayer(&backgroundLayer); 
  matrix.begin();

  matrix.setBrightness(128);

    backgroundLayer.drawString(1,2,{255,255,255},"init...");
    backgroundLayer.swapBuffers(true);
delay(2000);

}

void loop() {
}
embedded-creations commented 6 years ago

I believe this issue was from allocating a large amount of memory globally before call_start_cpu() is called. The memory likely spanned the boundaries of memory regions, even though the allocations were much smaller than the total amount of memory.

The macros SMARTMATRIX_ALLOCATE_BUFFERS() and SMARTMATRIX_ALLOCATE_BACKGROUND_LAYER() allocate memory, one with malloc for DMA memory, and one with a static buffer. Changing the static buffer to a malloc call in the constructor didn't help. The malloc calls all had to be moved inside setup(), after (I'm assuming) call_start_cpu() had properly set up the memory regions.

I committed fixes for the issue I was seeing (might be a similar issue, or might not be) to the SmartMatrix Library

twinotter commented 6 years ago

Thanks, Louis! This is definitely in the right direction. I wonder if the underlying system could be smarter with allocations though.. it seems like it should fail more gracefully.

embedded-creations commented 6 years ago

it seems like it should fail more gracefully.

I agree 100%

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] commented 5 years ago

This stale issue has been automatically closed. Thank you for your contributions.