Navigation

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

    Daanoz

    @Daanoz

    4
    Reputation
    11
    Posts
    507
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    Daanoz Follow

    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

    Latest posts made by Daanoz

    • RE: Powering my node

      @sundberg84 great thx, good news. The mysensors manual for battery powering makes it sound more easy than it is 😋.

      So, I've already got some step up convertors being shipped to me. But I'll order some low power sensor as well, just to be able to run them side by side and too see what happens (and i guess indeed to learn something new).

      I plan on using this manual to modify the arduino, does it cover the suggestion made by you?

      posted in Troubleshooting
      Daanoz
      Daanoz
    • RE: Powering my node

      Hi All,

      I think I've been hitting the same issue as well. Does anyone has some pointers to diagnose this problem?

      So if I read the above, the problem is caused by the DHT22 sensor? So Removing it from the board should solve it? Or is there more behind this?

      From what I've debugged, my node runs on battery @ 2.98v, and every 5 out of 6 resets the "radio init failed" message is shown, due to the fact that it's unable to do the "p" check (I guess because it doesn't have sufficient power). If it does boot up, it dies within a couple of hours with the pin13 led of the arduino pro mini active.

      But how is this related to the DHT22, since on boot-up the DHT22 is not yet being used?

      Also, swapping the DHT22 for a different sensor is a better solution then using a step-up convertor? Since the step-up convertor is always consuming power? How would this solve the problem for the NRF24 sensor, it would still not have enough, right?

      Thanks for any answers 🙂

      Daanoz

      posted in Troubleshooting
      Daanoz
      Daanoz
    • RE: Exception (28) on esp8266 Gateway, possible problem found?

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

      posted in Bug Reports
      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

      It's not really a brand... It's this one: http://www.aliexpress.com/item/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-For-Arduino-TE321/32574619454.html

      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
    • RE: [SOLVED] NRF24L01+ stops working

      The same issue here!

      I got a 'nice' FTDI adapter with 5v <-> 3.3v switch.... After experiencing the same, i noticed that the switch on the adapter is bogus and it always outputs 5v... 😲

      posted in Troubleshooting
      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

      Debugging futher...
      So if I understand correctly from the ESP8266 docs: boot mode 7, means boot from SPI FLASH (7 = 0111).

      I can disconnect 3 types of wires to get the boot procedure to run with: boot mode:(3,x)
      The boot flow changes if I disconnect either the VCC, GROUND or the CSN wire... But the boot is not always the same, I'll try to summarize:

      All pins of the NRF connected: boot mode:(7,7) - not booting
      Disconnect VCC pin, reset, reconnect after 1s: boot mode:(3,7) - booting, gateway working
      All pins connected: boot mode:(7,7) - not booting
      Disconnect CSN pin, reset, reconnect after 1s: boot mode:(3,7) - booting, gateway working
      All pins connected: boot mode:(7,7) - not booting

      So, this boot changes if I leave the pin disconnected for the full boot process (you'll get a radio init fail of course)

      All pins of the NRF connected: boot mode:(7,7) - not booting
      Disconnect VCC pin: boot mode:(3,7) - booting, gateway not working
      Reconnect VCC pin before reset: boot mode: (7,6) - not booting
      Disconnect VCC pin: boot mode:(3,6) - booting, gateway not working

      So guessing on the bootmodes: if the first integer is a 7, there is an error with the boot sequence, the second integer seems to be related to the NRF, did it fully run last time -> a 7, if I keep it out for a full boot sequence (including running of the gateway) we get a 6. Strange......

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

      Thanks, that already makes more sense:

       ets Jan  8 2013,rst cause:2, boot mode:(7,7)
      
      waiting for host
      

      From what I understand: 'rst cause: 2' means reset pin (or button?) being used, which I did.

      Boot mode (7, 7) is a bit more vague?

      posted in Troubleshooting
      Daanoz
      Daanoz