Exception (28) on esp8266 Gateway, possible problem found?

  • Hi,

    So i also started to having the Exception (28) issue on the 1.5.4 version:

    Exception (28):
    epc1=0x4000bf80 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
    ctx: cont
    sp: 3fff01c0 end: 3fff0470 offset: 01a0
    3fff0360:  3ffe8b70 3ffef41c 3ffef30b 40203606

    Actually for me I think updating to the newest Domoticz started causing it. One small note, I'm using the platform.io IDE, so I didn't manage to find out which board version I'm on or update to the 2.0.0 branch (libraries seems to be missing) as suggested in other topics... Also, inspecting the code of the 2.0.0 branch, it looks like it could cause the same issue...

    With a lot of serial.println statements I think i figured out what the issue is, let me try to explain. (Note: My knowledge of C is next no none, so i'm doing based on experiences with other programming languages)

    So, what (the latest) domoticz does (or even MYSController if you trigger it manually), is on start-up it requests the version number with the call 0;0;3;0;2;

    Documentation wise, it should be fine, it's just a message without a payload. Actually if you are hooked up to the serial, you'll see (at least in my case) the Exception (28) message.

    Tracing this, I think I found the reason why it's not working. You can test this by adding a payload to the message, for example: 0;0;3;0;2;test. It will probably not throw the exception...

    So, in the MyParserSerial.cpp file in the parse function on line 26, we see that value variable is initialized as null.

    bool MyParserSerial::parse(MyMessage &message, char *inputString) {
    	char *str, *p, *value=NULL;

    In the function it will start parsing the message, but only on the switch statement with the index position 5 it will actually set that value variable.

    For our message, which doesn't have a 5th index (number 6) the value will stay null.

    In the end of the function it will try to set the message in the message class:

    	if (command == C_STREAM) {
    		message.set(bvalue, blen);
    	} else {

    If we then look in the MyMessage.cpp file, it will actually trigger this function (I cannot really explain why)

    MyMessage& MyMessage::set(const char* value) {
    	uint8_t length = min(strlen(value), MAX_PAYLOAD);
    	strncpy(data, value, length);
    	return *this;

    The strlen in this case is feeded with the null value we got from the parse function, triggering the exception...

    So, I'm not sure what the best way is to solve this issue:

    • Initializing the value as a non null value
    • Adding a MyMessage::set method for catching null vars
    • Breaking out earlier of the MyParserSerial function if value is null
    • ....?

  • Admin

    This was fixed in the dev-branch


    But unfortunately never backported to 1.5

  • Aah, ok. I missed that. Thx, i'll apply the fix my self.

Log in to reply

Suggested Topics