Merge branch 'bugfix/id9561_bt_status_check' into 'master'
component/bt: bug fix of lack of checking bluetooth stack status inside API functions
Add an API function for checking bluetooth stack status: whether it is uninitialized, initialized or enabled.
The function is intended to be used by users to check the bluetooth stack status, also, it is used inside bluetooth API functions to ensure the stack is in valid state.
Ivan Grokhotkov [Wed, 11 Jan 2017 04:07:43 +0000 (12:07 +0800)]
Merge branch 'bugfix/crosscore_int_iram' into 'master'
Place cross-core interrupt into IRAM, sanity check handler address passed into esp_intr_alloc
Cross-core interrupt handler was not marked with IRAM_ATTR.
The reason why this caused an exception is probably due to some tasks running at highest priority (these are not blocked by spi_flash_disable_caches_interrupts_and_other_cpu mechanism).
This change puts the interrupt handler into IRAM and adds a sanity check into `esp_intr_alloc`.
Reported on Github: https://github.com/espressif/esp-idf/issues/211
Jeroen Domburg [Tue, 10 Jan 2017 06:01:07 +0000 (14:01 +0800)]
Merge branch 'feature/watchpoint_on_stack_canary' into 'master'
Add option to automatically set a watchpoint at the end of the swapped-in task
This should make stack overflows easier to debug because it triggers a debug exception as soon as the stack is overwritten, not later when a context switch happens. Marked as a FreeRTOS debug feature because it doesn't give a nice error message and uses up a watchpoint.
Jeroen Domburg [Tue, 10 Jan 2017 05:05:19 +0000 (13:05 +0800)]
Add documentation to panic handler functions, move watchpoint stuff from tasks.c to port.c, account for non-32-bytes-aligned stacks when setting watchpoint, add debug reason explanation to panic handler
Merge branch 'bugfix/detect_ocd_when_panic' into 'master'
Fix OpenOCD detection code
In the current master, detection of an attached OCD is broken. This fixes it.
I also snuck in two unrelated checks in intr_alloc which return from a function that is asserted earlier in the code. This makes the code behave better when they are called erroneously in a production build.
Ivan Grokhotkov [Mon, 9 Jan 2017 02:14:00 +0000 (10:14 +0800)]
Merge branch 'bugfix/bootloader_ets_cpu_update_freq' into 'master'
bootloader: export ets_update_cpu_frequency
MR !363 added linking librtc into bootloader. At the same time, MR !373 removed ets_update_cpu_frequency from ROM exports ld script, and replaced it with a dual CPU aware version. Combining these two MRs caused linker error in bootloader due to the unresolved `ets_update_cpu_frequency`.
One option to fix this is to move the definition of ets_update_cpu_frequency into bootloader_support component. This does however look a bit odd because this function is not something that is specifically needed for bootloader support.
Another option is to export the ROM version of ets_update_cpu_frequency for the bootloader only. This means that when bootloader changes CPU frequency, it only updates the tick period variable for PRO CPU. This isn't an issue though, because app startup code still calls the dual CPU aware version of ets_update_cpu_frequency early on, before any non-trivial code can run on the APP cpu.
This MR uses the second approach. Looking forward, we may move this definition of ets_update_cpu_frequency into the rtc_clk component, which will be used both by the bootloader and the app, and placing ets_update_cpu_frequency there would be logical.
This MR contains:
- SDMMC host peripheral driver
- SD protocol driver in sdmmc component (can be extended to support MMC/eMMC and SPI based hosts)
- ChaN's FATFS library v0.12b
- VFS integration
- FAT access via VFS is thread-safe (unless same file is read/written/unlinked/renamed from different tasks)
- Support for POSIX directory-related functions in VFS (and in vfs_fatfs.c)
- unit test for the above
- Example
- API documentation
Will be done in other MRs:
- Support for spi_flash IO driver for FatFs
- SPI host driver and support for SPI mode commands in sdmmc component
- MMC/eMMC support in sdmmc component
- Support for slightly higher 53/26.6MHz clocks (currently I'm using 20MHz for DS and 40MHz for HS, instead of 25MHz/50MHz per standard), and arbitrary low clocks (e.g. 4MHz).
Ivan Grokhotkov [Sat, 7 Jan 2017 10:50:12 +0000 (18:50 +0800)]
Merge branch 'feature/cplusplus' into 'master'
C++ support
This change adds necessary support for compiling C++ programs:
- linking against libstdc++
- implementation of static initialization guards using FreeRTOS primitives: since we don't have condition variables at our disposal, and we don't want to allocate a synchronization primitive for every guard variable generated by the compiler, we imitate condition variables using a combination of a mutex, counting semaphore, and a counter (based on [Microsoft Research paper](https://www.microsoft.com/en-us/research/wp-content/uploads/2004/12/ImplementingCVs.pdf), albeit because we don't need *arbitrary* code to use these CVs, implementation gets simpler).
Note that libstdc++ also contains an implementation of `__cxa_guard_{acquire,release,abort}` functions. These implementations come from an `#ifndef GXX_THREADS` branch, i.e. are not aware of multthreading. There are three ways of replacing these libstdc++ functions with our implementation:
1. Move our code into gcc. Pros: cleanest solution. Cons: Such changes are unlikely to be merged by any upstream, so we end up maintaining our own forks of {gcc,crosstool-ng}.
2. Use library as it is built by crosstool, use `ar` to delete one object file (`guards.o`), add this library to ESP-IDF. Pros: easy to implement. Cons: libstdc++ is a 15MB binary :hushed:
3. Keep using libstdc++ from crosstool, force our implementation to be linked using a `-u` linker flag. Pros: no impact on repo size, easy to implement. Cons: somewhat less clean than 1 (and about as hacky as 2).
For the reasons mentioned, option (3) looks like the best tradeoff.
Ivan Grokhotkov [Sat, 7 Jan 2017 10:46:10 +0000 (18:46 +0800)]
Merge branch 'feature/bootloader_rng' into 'master'
Enable bootloader entropy source for RNG
Enables an entropy source when bootloader starts up, which both seeds the RNG for use before WiFi/BT stack is enabled and provides an adequate RNG for secure boot & flash encryption key generation.
A prerequisite was enabling 80MHz operation, so the CPU is now set to 80MHz as soon as second stage bootloader starts running.
Ivan Grokhotkov [Sat, 7 Jan 2017 10:45:14 +0000 (18:45 +0800)]
Merge branch 'bugfix/ets_delay_on_app_cpu' into 'master'
esp32: ets_update_cpu_frequency should set tick scale for both CPUs
ets_update_cpu_frequency ROM function updates g_ticks_per_us, which is has two copies, one for each CPU.
The APP CPU copy of g_ticks_per_us never got updated, resulting in shorter delays produced by ets_delay_us on the APP CPU.
This MR replaces ROM ets_update_cpu_frequency with a copy in IRAM which updates scaling factors on both of the CPUs.
So now we get expected delays (in microseconds):
```
ets_delay_us core=0 expected=50000 actual=50014
ets_delay_us core=1 expected=50000 actual=50015
vTaskDelay core=0 expected=50000 actual=49428
vTaskDelay core=1 expected=50000 actual=50000
```
Reported on the forum: http://esp32.com/viewtopic.php?f=2&t=713#p3722
Jeroen Domburg [Fri, 6 Jan 2017 08:28:52 +0000 (16:28 +0800)]
Merge branch 'driver/spi' into 'master'
SPI master driver
This merge requests adds an SPI Master driver. This driver is (of course) multithread capable, has device abstraction, has command queueing, DMA support and all other sorts of nice things you'd expect from a SPI driver.
Ivan Grokhotkov [Fri, 6 Jan 2017 07:59:22 +0000 (15:59 +0800)]
Merge branch 'bugfix/tw9540_workaround_appdata_overwrite_bootdata' into 'master'
modify bootloader dram start address, swap app bss and data segments
Modify bootloader dram_seg from address 0x3ffc0000 to 0x3fff0000, len from 0x20000 to 0x10000.
Also put app .data before .bss, to reduce the chance .data collides with ROM bootloader stack.
Ivan Grokhotkov [Fri, 6 Jan 2017 05:03:07 +0000 (13:03 +0800)]
esp32: put .data before .bss
This change reduces chances that a large .bss segment will push .data all the way into
0x3ffe1320 — 0x3ffe5320 range where the bootloader stack is, creating a problem when
bootloader will be loading application into memory.
With this change, .data would need to be at least 200k big to cause problems.
Liu Zhi Fu [Fri, 6 Jan 2017 04:23:11 +0000 (12:23 +0800)]
bootloader: modify bootloader dram start address to 0x3fff0000
Modify bootloader dram_seg from address 0x3ffc0000 to 0x3fff0000, len from
0x20000 to 0x10000. Please be notified that this is just a workaround for
fixing app data overwrite bootloader data issue!
Wangjialin [Sun, 25 Dec 2016 15:11:24 +0000 (23:11 +0800)]
driver: ledc - update fading functions, add example and doc
1. add fading functions.
2. clear up ledc.c and ledc.h
3. update api doc.
4. add ledc example
5. edit ledc.rst and add readme for example code.
6. add s_ prefix for static global values.
7. add mutex for fade functions
8. minor changes according to the comments.
Wu Jian Gang [Thu, 5 Jan 2017 06:09:23 +0000 (14:09 +0800)]
Merge branch 'feature/throughput_optimization_phrase_1' into 'master'
lwip/freertos/esp32: add throughput optimization related code
1. Update wifi lib which contains ampdu and other optimizations
2. Add throughput code debug code
3. Add code to support sending multiple packet per socket call for udp
4. Other misc modification about throughput optimization
projects / esp-idf / log