In the situation when bootloader was compiled for 240MHz, and app was
compiled for 160MHz, and the chip is a revision 0 chip, the
bootloader will assume that the application has also been running at
240MHz. This will cause the chip to lock up later. Modify this to use
a run time check of DPORT_CPUPERIOD_SEL, which indicates which of the
PLL frequencies was used.
Closes https://github.com/espressif/esp-idf/issues/2731.
1. When one of the COMPONENT_DIRS points to a component directory
(i.e. a directory containing component.mk, not a directory of multiple
components), and there is a subdirectory in it which also contains
a component, the subdirectory was mistakenly added to the list of
components and compiled.
For example:
main/
component.mk
main.c
test/
component.mk
test_main.c
Would compile test_main.c and link libtest.a.
2. When one of the COMPONENT_DIRS points to a component directory, and
the parent directory contained a directory with the same name as
another component, that directory would be mistakenly added to the
COMPONENT_PATHS.
For example:
esp/
esp-idf/
esp32/
(random stuff)
mycomponent/
component.mk
mycomponent.c
myproject/
main/
Makefile
and Makefile sets EXTRA_COMPONENT_DIRS=$(realpath ../mycomponent),
then "esp32" directory which is at the same level as mycomponent
was added to COMPONENT_PATHS.
3. If EXTRA_COMPONENT_DIRS pointed to a directory with a list of
components, and one of the subdirectories was not a component, but
had the same name as another component, than that directory would be
mistakenly added to COMPONENT_PATHS instead of the real esp32
component directory.
For example:
my_components/
my_component/
component.mk
my_component.c
esp32/
(some random stuff)
and EXTRA_COMPONENT_DIRS would point to my_components/, then "esp32"
directory would be added to COMPONENT_PATHS instead of the real esp32
component directory.
when running a query for a single txt, result entries were not created and attached to result structure. this issue was introduced when fixing memory leak in txt structure, which worked correctly for PTR queries, but caused trouble for TXT query.
The bug will cause memory corrupted (the largest range is from 0x3ffc0000 ~ 0x3ffc8000),
some strange error will happen, like IllegalInstruction, LoadProhibited and .etc.
Note : Examples have been updated to prevent invocation of bluedroid/wifi APIs from inside timer callback when stopping provisioning. Workaround is to spawn new task from inside the timer callback.
List of changes:
* Corner case exceptions are properly handled to ensure release of memory occupied by security infrastructure
* fixed erroneous cleanup of security instance by protocomm_console
List of changes:
* Version endpoint now sends the set version string instead of verifying the incoming version string. This simplifies fetching version info from the provisioning application.
* esp_prov script updated to expect version string as response.
This will be useful if a webserver is already running and the application
does not want protocomm to start a new instance.
Signed-off-by: Piyush Shah <piyush@espressif.com>
