Crash when sending PROGMEM char array.

[adrian-dybwad]

Basic Infos

• [x ] This issue complies with the issue POLICY doc.
• [ x] I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• [x ] I have searched the issue tracker for a similar issue.
• [x ] If there is a stack dump, I have decoded it.
• [x ] I have filled out all fields below.

Platform

• Hardware: [WROMM-02]
• Core Version: [2.5.1]
• Development Env: [Arduino IDE]
• Operating System: [MacOS]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [dio]
• Flash Size: [1MB]
• lwip Variant: [v2 Higher Bandwidth]
• Reset Method: [nodemcu]
• Flash Frequency: [80Mhz]
• CPU Frequency: [160MHz]
• Upload Using: [SERIAL]
• Upload Speed: [other] (serial upload only)

Problem Description

When running the sketch below and using nonos-sdk 2.2.1 or 2.2.2, the sketch crashes. It works fine with nonos-sdk pre 3. I confirmed this on another computer with a fresh install of Arduino. It works when the char[] is not in PROGMEM.

MCVE Sketch

const char someMessage[] PROGMEM = "Some Message";
void setup() {
  Serial.begin(115200);
  Serial.println(someMessage);
}

void loop() {
}

Debug Messages

Exception (3):
epc1=0x402024bd epc2=0x00000000 epc3=0x00000000 excvaddr=0x40236a80 depc=0x00000000

>>>stack>>>

ctx: cont
sp: 3ffffda0 end: 3fffffc0 offset: 01a0
3fffff40:  40202829 00000001 3ffeeeec 3ffee26c  
3fffff50:  3fffdad0 00000000 3ffee214 402010bc  
3fffff60:  feefeffe 00000001 3ffee214 40201299  
3fffff70:  40236a80 00000001 3ffee214 40201230  
3fffff80:  0001c200 0000001c 3ffee214 402012d1  
3fffff90:  feefeffe 00000000 3ffee214 40201040  
3fffffa0:  feefeffe feefeffe 3ffee23c 40201778  
3fffffb0:  feefeffe feefeffe 3ffe84f4 40100459  
<<<stack<<<

Exception 3: LoadStoreError: Processor internal physical address or data error during load or store
PC: 0x402024bd: uart_write(uart_t*, char const*, size_t) at /Users/adriandybwad/Library/Arduino15/packages/esp8266/hardware/esp8266/2.5.1/cores/esp8266/uart.cpp line 498
EXCVADDR: 0x40236a80

Decoding stack results
0x40202829: uart_init(int, int, int, int, int, size_t) at /Users/adriandybwad/Library/Arduino15/packages/esp8266/hardware/esp8266/2.5.1/cores/esp8266/uart.cpp line 661
0x402010bc: HardwareSerial::write(unsigned char const*, unsigned int) at /Users/adriandybwad/Library/Arduino15/packages/esp8266/hardware/esp8266/2.5.1/cores/esp8266/HardwareSerial.h line 158
0x40201299: Print::write(char const*) at /Users/adriandybwad/Library/Arduino15/packages/esp8266/hardware/esp8266/2.5.1/cores/esp8266/Print.h line 60
0x40201230: HardwareSerial::begin(unsigned long, SerialConfig, SerialMode, unsigned char) at /Users/adriandybwad/Library/Arduino15/packages/esp8266/hardware/esp8266/2.5.1/cores/esp8266/HardwareSerial.cpp line 51
0x402012d1: Print::println(char const*) at /Users/adriandybwad/Library/Arduino15/packages/esp8266/hardware/esp8266/2.5.1/cores/esp8266/Print.cpp line 121
0x40201040: setup() at /Users/adriandybwad/Google Drive/Arduino/SerialPrintCrashIn2.5.1/SerialPrintCrashIn2.5.1.ino line 6
0x40201778: loop_wrapper() at /Users/adriandybwad/Library/Arduino15/packages/esp8266/hardware/esp8266/2.5.1/cores/esp8266/core_esp8266_main.cpp line 122

[TD-er]

Maybe related to this PR? #6101

[earlephilhower]

No, that PR will give compile-time errors, and no runtime (since no binaries would be generated).

[earlephilhower]

3.0pre had a SW fixup routine to handle unaligned progmem accesses. That's not present on the 2.2x, so you need to use Serial.printf_Por the UART will attempt to read progmem in byte-wise fashion and crash.

3.0pre also had the nasty habit of randomly freezing inside the binary blobs and running significantly slower than earlier blob releases, so it was dropped and we rolled back to 2.x.

[Qrome]

I am seeing this same exception when using PROGMEM variables in 2.5.2 core. The 2.5.0 core seems to work fine with the code however. Is there any updates on this issue?

[d-a-v]

Is there any updates on this issue?

There is so far no issue as @earlephilhower states above.
The rule is that *_P() functions (or pgm_read_*()) are needed when accessing PROGMEM.
in core-2.5.0 using espressif sdk-pre3, there was an exception handler that would allow to use PROGMEM without _P()-functions, but with a high performance cost. We had to revert back to sdk-2.2 for other reasons. So this handler is not there anymore. *_P() are needed in core-2.5.1 or -2.5.2 (as in -2.2, -2.3 and -2.4).

[Qrome]

Got, it. Converted to use P function for reading PROGMEM -- working now. Thanks.

[devyte]

Closing since there isn't much we can do on our side.

[adrian-dybwad]

Surely this should cause a compile time error though? The app will compile and crash at runtime, allowing an instance of this to be hidden deep in the code somewhere. Not good.