Merge branch 'bugfix/small_fixes_github' into 'master'

Some small fixes from Github

See merge request !1737

components/driver/rmt.c

@@ -540,7 +540,6 @@ static void IRAM_ATTR rmt_driver_isr_default(void* arg)
                 switch(i % 3) {
                     //TX END
                     case 0:
-                        ESP_EARLY_LOGD(RMT_TAG, "RMT INTR : TX END");
                         xSemaphoreGiveFromISR(p_rmt->tx_sem, &HPTaskAwoken);
                         if(HPTaskAwoken == pdTRUE) {
                             portYIELD_FROM_ISR();
@@ -552,7 +551,6 @@ static void IRAM_ATTR rmt_driver_isr_default(void* arg)
                         break;
                         //RX_END
                     case 1:
-                        ESP_EARLY_LOGD(RMT_TAG, "RMT INTR : RX END");
                         RMT.conf_ch[channel].conf1.rx_en = 0;
                         int item_len = rmt_get_mem_len(channel);
                         //change memory owner to protect data.
@@ -590,7 +588,7 @@ static void IRAM_ATTR rmt_driver_isr_default(void* arg)
                 channel = i - 24;
                 rmt_obj_t* p_rmt = p_rmt_obj[channel];
                 RMT.int_clr.val = BIT(i);
-                ESP_EARLY_LOGD(RMT_TAG, "RMT CH[%d]: EVT INTR", channel);
+
                 if(p_rmt->tx_data == NULL) {
                     //skip
                 } else {

components/freertos/include/freertos/event_groups.h

@@ -133,7 +133,7 @@ typedef TickType_t EventBits_t;
  *
  * Internally, within the FreeRTOS implementation, event groups use a [small]
  * block of memory, in which the event group's structure is stored.  If an event
- * groups is created using xEventGropuCreate() then the required memory is
+ * groups is created using xEventGroupCreate() then the required memory is
  * automatically dynamically allocated inside the xEventGroupCreate() function.
  * (see http://www.freertos.org/a00111.html).  If an event group is created
  * using xEventGropuCreateStatic() then the application writer must instead

docs/api-reference/system/esp_timer.rst

@@ -6,7 +6,7 @@ Overview
 
 Although FreeRTOS provides software timers, these timers have a few limitations:
 
-- Mmaximum resolution is equal to RTOS tick period
+- Maximum resolution is equal to RTOS tick period
 - Timer callbacks are dispatched from a low-priority task
 
 Hardware timers are free from both of the limitations, but often they are less convenient to use. For example, application components may need timer events to fire at certain times in the future, but the hardware timer only contains one "compare" value used for interrupt generation. This means that some facility needs to be built on top of the hardware timer to manage the list of pending events can dispatch the callbacks for these events as corresponding hardware interrupts happen.

docs/get-started/index.rst

@@ -285,7 +285,7 @@ To exit the monitor use shortcut ``Ctrl+]``.
         e<><65><EFBFBD>)(Xn@<40>y.!<21><>(<28>PW+)<29><>Hn9a؅/9<>!<21>t5<74><35>P<EFBFBD>~<7E>k<EFBFBD><6B>e<EFBFBD>ea<65>5<EFBFBD>jA
         ~zY<7A><59>Y(1<>,1<15><> e<><65><EFBFBD>)(Xn@<40>y.!Dr<44>zY(<28>jpi<70>|<7C>+z5Ymvp
 
-    or monitor fails shortly after upload, your board is likely using 26MHz crystal, while the ESP-IDF assumes default of 40MHz. Exit the monitor, go back to the :ref:`menuconfig <get-started-configure>`, change :ref:`CONFIG_ESP32_XTAL_FREQ_SEL` to 26MHz, then :ref:`build and flash <get-started-build-flash>` the application again.
+    or monitor fails shortly after upload, your board is likely using 26MHz crystal, while the ESP-IDF assumes default of 40MHz. Exit the monitor, go back to the :ref:`menuconfig <get-started-configure>`, change :ref:`CONFIG_ESP32_XTAL_FREQ_SEL` to 26MHz, then :ref:`build and flash <get-started-build-flash>` the application again. This is found under ``make menuconfig`` under Component config --> ESP32-specific --> Main XTAL frequency.
 
 To execute ``make flash`` and ``make monitor`` in one go, type ``make flash monitor``. Check section :doc:`IDF Monitor <idf-monitor>` for handy shortcuts and more details on using this application.
 

examples/storage/sd_card/README.md

@@ -37,6 +37,8 @@ With the given pinout for SPI mode, same connections between the SD card and ESP
 
 GPIO2 pin is used as a bootstrapping pin, and should be low to enter UART download mode. One way to do this is to connect GPIO0 and GPIO2 using a jumper, and then the auto-reset circuit on most development boards will pull GPIO2 low along with GPIO0, when entering download mode.
 
+- Some boards have pulldown and/or LED on GPIO2. LED is usually ok, but pulldown will interfere with D0 signals and must be removed. Check the schematic of your development board for anything connected to GPIO2. 
+
 ### Note about GPIO12
 
 GPIO12 is used as a bootstrapping pin to select output voltage of an internal regulator which powers the flash chip (VDD_SDIO). This pin has an internal pulldown so if left unconnected it will read low at reset (selecting default 3.3V operation). When adding a pullup to this pin for SD card operation, consider the following: