Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. Daanoz
    3. Best
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Best posts made by Daanoz

    • [SOLVED] ESP8266 fails to boot with NRF24L01+ connected

      The last couple of days I have been using a ESP8266 board to use as gateway for the sensor network.

      Currently I'm having some issues with booting the board, whenever the NRF24L01+ is connected, it won't start. Instead it spits out some random gibberish on the serial console and that's it. As soon as I remove the VCC connection to the NRF module, it starts to work again when I reset the board. If I reconnect the NRF module when the ESP is trying to connect to the WIFI, everything works fine, the gateway is just working like it's supposed to.

      I tried some different things, all not (yet) successful:

      • Ordered (not yet tried) some 47uF capacitors (I only have some 100uF capacitors lying around)
      • Different power supplies:
        • 3 different pc's
        • 2 USB power adapters (750mA & 1A)
        • USB hub, rated @ 1200mA
      • Measuring the VCC - GND output: 3.28V
      • Using a different NRF Module

      Any advise is welcome (while I'm waiting for the capacitors to come in).

      Thanks.

      Daanoz

      posted in Troubleshooting
      Daanoz
      Daanoz
    • 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
      
      >>>stack>>>
      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 {
      		message.set(value);
      	}
      

      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);
      	miSetLength(length);
      	miSetPayloadType(P_STRING);
      	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
      • ....?
      posted in Bug Reports
      Daanoz
      Daanoz
    • RE: [SOLVED] ESP8266 fails to boot with NRF24L01+ connected

      Got it solved!

      Ok, after debugging for a while: the problem is with the CSN pin on GPIO pin 15. Pin 15 is also used in the ESP8266 to define boot from SD card. Somehow, at least in my case, after a reset, the NRF chip sets the CSN pin to high (measured it with a multimeter), causing the ESP8266 to start the SD-card procedure, which fails of course. The solution for me is swapping the pins for inclusion with the CSN pin:

      So:
      CSN -> GPIO 5 -> D1
      Inclusion mode -> GPIO 15 -> D78

      One question though: I also seem to have SPI pins on the other side of the Devkit, why aren't those used?

      posted in Troubleshooting
      Daanoz
      Daanoz
    • RE: [SOLVED] ESP8266 fails to boot with NRF24L01+ connected

      Ok, another small update from my side. I think I localized the root cause of what was putting my CSN in a high state.

      Last couple of days I was testing with a sensor connected with power through a FTDI adapter, the adapter had a nice switch to chose between 3.3v and 5v. The sensor was actually having a problem, this problem to be precise, the sensor fails after a couple of hours. At first I didn't think much about it, since the switch was on 3.3v. After having 2 NRF chips failing, I measured the output of the 3.3v pin on the arduino pro mini, you guessed it: 5V! 😭

      The funny thing is, the first chip that failed, I used on the gateway to test if it was working, because it did work without a reset, I didn't think much about it. Now I know that the 5V Probaly fried something in the chip, causing to output high on the CSN in some cases...

      Attached a photo of the second chip that fried even more (the right one with the 2 black blobs below the chip). Anyway, thanks for the help folks, finally can start building something!

      right chip after 5v

      posted in Troubleshooting
      Daanoz
      Daanoz