Documentation Requests/Feedback

bkgoodman
Posts: 45
Joined: Fri Feb 17, 2017 12:41 pm

Re: Document Requests

Postby bkgoodman » Sun Mar 26, 2017 2:43 pm

RTC watchdog is COMPLETELY undocumented. Seeing how it is the only mechanism to do an main system reset, the is very important to me. I saw a reference to some registers used

ESP_Sprite
Posts: 9766
Joined: Thu Nov 26, 2015 4:08 am

Re: Document Requests

Postby ESP_Sprite » Mon Mar 27, 2017 1:37 am

The RTC documentation in general is still a work-in-progress... if it's any help, the RTC watchdog, apart from the reset stages (which iirc do a SoC reset instead of a CPU reset), is exactly the same as the timer group watchdogs. Also, if you want to reset the chip, does the ROM function software_reset() not do what you want?

bkgoodman
Posts: 45
Joined: Fri Feb 17, 2017 12:41 pm

Re: Document Requests

Postby bkgoodman » Mon Mar 27, 2017 12:07 pm

I *really* need to the RTC watchdog - because I need my circuit to be able to perform a full-system-reset in the event of something bad happening. (It is being designed for installation in a 7/24 lights-out [remote] environment. I have already seen cases where some of the libraries - like Secure WiFi can crash on some edge cases. I need the chip to hard-reset itself out of such scenarios).

novalight
Posts: 40
Joined: Tue Apr 19, 2016 1:13 pm

Re: Document Requests

Postby novalight » Wed Mar 29, 2017 12:11 pm

I would also appreciate a thorough documentation of TASK- and RTC-Watchdog. Our use case is the same as bkgoodman. Some of our products are used in really remote areas were user reset is not an option or would cause a technician to drive several hundreds of kilometers to do a manual reset.
Since we also have seen lockups after crashes (even with the option to "reboot on exception" set in sdkconfig) this pretty much ruins these product.
Of course we could still add a "hardware watchdog" by means of circuitry but that would add a really unpleasant layer of complexity to our products.

So I would request the WDT docs and also an example/best practice/guide or whatever on how to prevent lockups in software.

bkgoodman
Posts: 45
Joined: Fri Feb 17, 2017 12:41 pm

Re: Document Requests

Postby bkgoodman » Wed Mar 29, 2017 1:03 pm

Yep - Exactly what Novalight said ;-)

User avatar
rudi ;-)
Posts: 1729
Joined: Fri Nov 13, 2015 3:25 pm

Re: Document Requests

Postby rudi ;-) » Fri Jun 16, 2017 1:15 am

Hi

there was a Wrover Guide Request in the past from me
now found and spottet in the wild :
first release 2017 05 is here
SP_Wrover_User_Guide_s.png
SP_Wrover_User_Guide_s.png (32.82 KiB) Viewed 22973 times
with SSC Command Reference

not sure when it comes to the resource of espressif document side
in the meantime you can take this
ESP-WROVER_User_Guide.pdf
User Guide PDF Version
English
(268.7 KiB) Downloaded 5761 times
best wishes
rudi ;-)
Last edited by rudi ;-) on Sat Jun 17, 2017 11:45 am, edited 1 time in total.
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪

aknkotts7256
Posts: 2
Joined: Fri Jun 16, 2017 5:22 am

Re: Document Requests

Postby aknkotts7256 » Fri Jun 16, 2017 5:53 am

Hello,

Just saw this thread. I'd like to request the pinout for the Geekcreit/DOIT esp32 VROOM-32 devkit V1, a "clean" version. doit.am posts no data for their product. The supplied pdf schematic makes it too difficult for quick pin reference when coding.

Thank you for the help,

Alex

raemond
Posts: 2
Joined: Wed Jul 12, 2017 6:13 pm

Re: Document Requests

Postby raemond » Wed Jul 12, 2017 6:16 pm

I am looking for the certification guide (ESP32_Certification_and_Test_Guide__EN.pdf). I have seen it referenced in the forums but can't find it anywhere.

User avatar
loboris
Posts: 514
Joined: Wed Dec 21, 2016 7:40 pm

Re: Document Requests

Postby loboris » Wed Jul 12, 2017 7:43 pm


robbym
Posts: 4
Joined: Tue Mar 28, 2017 1:00 am

Re: Document Requests

Postby robbym » Sun Jul 16, 2017 7:00 pm

If I want to port the esptool.py to another language, is there a document somewhere specifying the protocol used to communicate with the ROM bootloader? Or do I have to infer it from the python source? I will do the latter if the former isn't available, but having documentation would speed up the process.

Who is online

Users browsing this forum: No registered users and 13 guests