spleenware / ripple

Arduino Firmware for Ripple LoRa mesh
Other
261 stars 32 forks source link

Strange bootloop #35

Closed imayoda closed 3 years ago

imayoda commented 3 years ago

Hi there, I have tried to install firmware on my brand new ttgo lora (the one with microusb mounted on the side) but suddenly after successful firmware flash, serialconsole says: [19:28:35]rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) [19:28:35]configsip: 188777542, SPIWP:0xee [19:28:35]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 [19:28:35]mode:DIO, clock div:1 [19:28:35]load:0x3fff0018,len:4 [19:28:35]load:0x3fff001c,len:1044 [19:28:35]load:0x40078000,len:8896 [19:28:35]load:0x40080400,len:5816 [19:28:35]entry 0x400806ac [19:28:35]ets Jun 8 2016 00:22:57 [19:28:35]

It seems to me like a bootloop, but as I'm a newbie with esp32 (have had only esp8266 until today) I'm kindly asking for some guidance. Thanks a lot

spleenware commented 3 years ago

Could you include a link to the product page, or the page where you ordered your TTGO module from? Am just not sure it's one that Ripple currently supports.

On Sun, Mar 28, 2021 at 5:34 AM imayoda @.***> wrote:

Hi there, I have tried to install firmware on my brand new ttgo lora (the one with microusb mounted on the side) but suddenly after successful firmware flash, serialconsole says: [19:28:35]rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) [19:28:35]configsip: 188777542, SPIWP:0xee [19:28:35]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 [19:28:35]mode:DIO, clock div:1 [19:28:35]load:0x3fff0018,len:4 [19:28:35]load:0x3fff001c,len:1044 [19:28:35]load:0x40078000,len:8896 [19:28:35]load:0x40080400,len:5816 [19:28:35]entry 0x400806ac [19:28:35]ets Jun 8 2016 00:22:57 [19:28:35]

It seems to me like a bootloop, but as I'm a newbie with esp32 (have had only esp8266 until today) I'm kindly asking for some guidance. Thanks a lot

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/spleenware/ripple/issues/35, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIVWJM5ZYWH6LLXYQKBSOTTFYQKLANCNFSM4Z5FPVLA .

imayoda commented 3 years ago

@spleenware , sure no problem. here it is: https://it.aliexpress.com/item/4000632993971.html

spleenware commented 3 years ago

Hmm, I haven't tried this one so can't promise that it will work. I notice it's in the 433MHz band. You will need to go to the Preferences in the Ripple Messenger app (is that the one you are using?) and set the Frequency to something in that band. See the wiki for details: https://github.com/spleenware/ripple/wiki

Not sure if the frequency explains the crash though, but it's worth a try.

On Sun, Mar 28, 2021 at 11:07 AM imayoda @.***> wrote:

@spleenware https://github.com/spleenware , sure no problem. here it is: https://it.aliexpress.com/item/4000632993971.html

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spleenware/ripple/issues/35#issuecomment-808820679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIVWJJ6ENWCGEFCPVWLZMLTFZXLRANCNFSM4Z5FPVLA .

spleenware commented 3 years ago

The only other thing I can think of is if you have done any wiring of the pins to peripherals, disconnect all of them and try booting up and see if there is any difference.

On Sun, Mar 28, 2021 at 11:17 AM Scott Powell @.***> wrote:

Hmm, I haven't tried this one so can't promise that it will work. I notice it's in the 433MHz band. You will need to go to the Preferences in the Ripple Messenger app (is that the one you are using?) and set the Frequency to something in that band. See the wiki for details: https://github.com/spleenware/ripple/wiki

Not sure if the frequency explains the crash though, but it's worth a try.

On Sun, Mar 28, 2021 at 11:07 AM imayoda @.***> wrote:

@spleenware https://github.com/spleenware , sure no problem. here it is: https://it.aliexpress.com/item/4000632993971.html

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spleenware/ripple/issues/35#issuecomment-808820679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIVWJJ6ENWCGEFCPVWLZMLTFZXLRANCNFSM4Z5FPVLA .

imayoda commented 3 years ago

it actually is a 868/915MHz ... there's a photo of it i managed to take.. when it boots there's only a green led looping on and of and the console replicates that message continously on and on image: https://www.dropbox.com/s/hxq6go2b6pza16p/IMG_20210328_013210.jpg?dl=0 p.s. no peripherals at all only microsub connected :(

spleenware commented 3 years ago

Just wondering which particular firmware Bin file you flashed? Was is this one: RippleV3-USB-TTGOV2.bin https://github.com/spleenware/ripple/blob/master/RippleV3-USB-TTGOV2.bin (for USB-OTG) -or- RippleV3-Bluetooth-TTGOV2.bin https://github.com/spleenware/ripple/blob/master/RippleV3-Bluetooth-TTGOV2.bin (for Bluetooth)

On Sun, Mar 28, 2021 at 11:36 AM imayoda @.***> wrote:

it actually is a 868/915MHz ... there's a photo of it i managed to take.. when it boots there's only a green led looping on and of and the console replicates that message continously on and on image: https://www.dropbox.com/s/hxq6go2b6pza16p/IMG_20210328_013210.jpg?dl=0

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spleenware/ripple/issues/35#issuecomment-808823520, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIVWJO22CAVNWXRI3E2OJLTFZ2X7ANCNFSM4Z5FPVLA .

imayoda commented 3 years ago

I've tried both, with same identical output

spleenware commented 3 years ago

To eliminate whether it is a problem with the devices themselves, and not Ripple, try flashing these Arduino sketches onto them to verify that basic LoRa data can be transmitted, etc: https://github.com/LilyGO/TTGO-LORA32

imayoda commented 3 years ago

ok, will come back with results asap.. meanwhile thanks a lot for supporting :)

imayoda commented 3 years ago

https://www.dropbox.com/s/5dipmqa00lvilll/IMG_20210329_133828.jpg?dl=0

Hi there, both transmitter and receiver are working with previously linked examples.. but same debug output when loading ripple firmware (V3bluetooth and usb). I'm totally noob on esp32 territory, but is this related? https://github.com/espressif/arduino-esp32/issues/796

spleenware commented 3 years ago

I'll order one of these TTGO's and see if I can debug. Will take weeks for it to arrive, so can't promise anything until after then.

On Mon, Mar 29, 2021 at 11:05 PM imayoda @.***> wrote:

https://www.dropbox.com/s/5dipmqa00lvilll/IMG_20210329_133828.jpg?dl=0

Hi there, both transmitter and receiver are working with previously linked examples.. but same debug output when loading ripple firmware (V3bluetooth and usb). I'm totally noob on esp32 territory, but is this related?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spleenware/ripple/issues/35#issuecomment-809323406, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIVWJL6PWXRFVWE26XVRWDTGB3ITANCNFSM4Z5FPVLA .

imayoda commented 3 years ago

@spleenware thank you so much, meanwhile if i get any news, i'll let you know :)

spleenware commented 3 years ago

Have been trying to figure out why your board + the Ripple firmware is resulting in anything to do with the ESP32 deep sleep stuff. Anyway, as a test, I have compiled an experimental firmware. Could you try this one and let me know if any different? https://drive.google.com/file/d/174tOqQ8bnt8cFTXr1pwClI3wOjJvEBVZ/view?usp=sharing

imayoda commented 3 years ago

Just tried it, same output it seems.. `Using 'COM43' as serial port. Connecting...... Detecting chip type... ESP32 Connecting......

Chip Info:

Leaving... Hard Resetting... Done! Flashing is complete!

Showing logs: [04:48:03]ets Jun 8 2016 00:22:57 [04:48:03] [04:48:03]rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) [04:48:03]configsip: 188777542, SPIWP:0xee [04:48:03]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 [04:48:03]mode:DIO, clock div:1 [04:48:03]load:0x3fff0018,len:4 [04:48:03]load:0x3fff001c,len:1044 [04:48:03]load:0x40078000,len:8896 [04:48:03]load:0x40080400,len:5816 [04:48:03]entry 0x400806ac [04:48:03]ets Jun 8 2016 00:22:57 [04:48:03]`

spleenware commented 3 years ago

OK, thanks for trying. This has me stumped. :-( Will have to wait until my one arrives, and try debugging myself.

imayoda commented 3 years ago

thanks for support! I'll wait patiently :)

spleenware commented 3 years ago

I have the board I ordered now, and have reproduced the boot looping. So, now just have to figure out why...

spleenware commented 3 years ago

OK, I have uploaded a new firmware which fixes this. For some reason, this board doesn't report the VBAT voltage like the other model does. So, you'll see '0.0 V' wherever battery voltage is displayed. But, it shouldn't do the boot loop now. Bin file is: https://github.com/spleenware/ripple/blob/master/RippleV5-USB-TTGOV2.bin

spleenware commented 3 years ago

You can actually add a voltage divider circuit of your own to this TTGO board, to get the battery voltage measurement feature back (this is built in with the other model). See this pic on how to do the wiring: https://drive.google.com/file/d/1R_8oZs-_j3IgjieF86mWgC3_AvRvRKYl/view?usp=sharing You just need two resistors with the same resistance, somewhere between 10-50K Ohms is standard. The yellow wire pictured needs to go to PIN 35.

imayoda commented 3 years ago

just finished a 2 device test (one android 10 and one on 5 version), all is awesome, will do the battery mod you kindly suggested asap.. don't know why they missed out the connections that are present on older versions (i do think it's because there are many fake of fake devices, that are already clones of the originals). Is there support for bluetooth version on this board ? many thanks for all so far (closing issue indeed) :)

spleenware commented 3 years ago

Have just uploaded a V5 Bluetooth bin file, so you can try that also.

imayoda commented 3 years ago

it works so good, in the following weeks we'll do range discovery tests (we are dispersed on very mixed terrain), after that a pair of repeaters are 99% almost confirmed, so i'll buy some software for it :) just a question, are these boards now supported by repeater/mailoffice firmwares (or will them be) ? just asking because i can get them easier than other models. kind regards and thanks a lot

spleenware commented 3 years ago

I will upload a V5 repeater firmware for the TTGOs very soon. However, in the longer term, I highly recommend the Heltec V2's for repeaters. I have had good success with them, and also I have a new firmware coming out soon, just for the Heltecs, which have a super efficient deep sleep. ie. they wake up from deep sleep on receiving LoRa data, do their thing for a few seconds, then go back to sleep. Battery life tests have been amazing.

imayoda commented 3 years ago

will keep this advice in good consideration, deepsleep on repeaters is a great thing to have ! just another question, the advanced tab in messenger app supports frequency selection, how does this function and what values could go there? And the spreading factor is something that modulates the maximum area coverage? thnx again

spleenware commented 3 years ago

The custom frequency is mostly for European-based users, who need to be within the 863-870 ISM band. For North America and Australia, we use the 902-928 band. So you can enter integers in these ranges in the Advanced section. The spreading factor selection is: 10, 11 or 12. I added this more for experimental reasons, and find the default (10) is best. The higher the number the greater the range, but the longer the transmit time is. (by exponential factor!) 12 takes far too long to be practical, in my opinion.

imayoda commented 3 years ago

thanks for explanations, i guess i'm going to find out really soon how much spreading factor is impacting on range of transmission and will observe transmission speed.. we live in italy which is not a flatland for sure :)

spleenware commented 3 years ago

Hi,

I have designed a case for this TTGO board: https://www.thingiverse.com/thing:4840355

BPouet commented 1 year ago

Hi! I have the same bootloopwith the LILYGO TTGO T3 V1.6.1

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 188777542, 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:0x3fff0030,len:1184 load:0x40078000,len:13220 ho 0 tail 12 room 4 load:0x40080400,len:3028 entry 0x400805e4

I get this with V3 and V5 of RippleV5-Bluetooth-TTGOV2

After a lot of research, I came upon people speaking of problems of bootloop with OLED that doesn't have a reset pin or are not conneted causing the problem. https://github.com/lnlp/LMIC-node/issues/45

`I had the same Issue with my TTGO LoRa32 V2.1.6 board. I was able to "fix" the bootloop by changing the value in pins_arduino.h from

define OLED_RS 16

to

define OLED_RS -1

I can't really explain why it works, but my collague, who suggested the fix, said something along the lines of cheaper OLED Displays dont connect the reset Pin, which causes these kinds of Problems.`

Which is the only fair solution that I see at the moment.

Same problem bootproblem with my Lilygo T-BEAM but this one doesn't have a OLED screen. 21:11:39.493 -> rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) 21:11:39.528 -> invalid header: 0x6f757126 21:11:39.604 -> invalid header: 0x6f757126 21:11:39.642 -> invalid header: 0x6f757126 21:11:39.675 -> invalid header: 0x6f757126 21:11:39.714 -> invalid header: 0x6f757126 21:11:39.785 -> invalid header: 0x6f757126 21:11:39.819 -> invalid header: 0x6f757126

Thanks!