if COAP_CONSTRAINED_STACK is defined (is for esp-idf), the mutexes set up to protect the critical sections were not working as expected and were just dummy entries.

Use the pthread_ version of the mutex instead by defining HAVE_PTHREAD_H and HAVE_PTHREAD_MUTEX_LOCK.

Love the esp_encrypted_img component and I've been trying it out in a C++ ESP IDF project, this PR just addresses a few small issues I found.

The first is that the esp_encrypted_img_<whateever> functions currently accept esp_decrypt_handle_t* parameter rather than a esp_decrypt_handle_t. This is not correct and produces compiler errors in C++ (esp_decrypt_handle_t is already the handle pointer)

The next is that there seemed a bunch of unnecessary memory allocations with (calloc()), moving the gcm_key and iv directly into the esp_encrypted_img_handle only adds 48 bytes to it (and it is already dynamically allocated), and also simplifies the setup/error handling. Likewise, got_auth is only 16 bytes and can be allocated on the stack.

Finally, there was a possible memory leak of rsa_pem, if esp_encrypted_img_decrypt_end() was called without doing any decryption. This might happen if you wanted to cancel the decryption (e.g. a network error meant you could not download the firmware).

I would like to request that the version of libcoap be bumped to a more recent commit.

With the current commit https://github.com/obgm/libcoap/tree/3aa11612c143c9734d72022720f33e12506f7a2c, I ran into issues related to blockwise GET transfers. After investigating, I realized that it was a bug that has since been fixed in libcoap. I don't recall the specifics of the bug, or which PR/commit fixed it, but I might be able to find out if that's needed.

For my use, I forked the coap component, and updated libcoap to https://github.com/obgm/libcoap/tree/50128de191d558593bc9a48a08eb04735f942e45. This fixed the blockwise GET issues. However, it's not ideal for me to maintain the fork, and it would preferable if it could be updated here in this repo.

Checklist

• [x] Component contains License
• [x] Component contains README.md
• [x] Component contains idf_component.yml file with url field defined
• [x] Component was added to upload job
• [x] Component was added to build job
• [x] Optional: Component contains unit tests
• [ ] CI passing

Change description

Please describe your change here

This is the first step to fix IDF's format warnings.

IDF has globally enabled compiler option -Wno-format. The fix will be in three steps:

1. add -Wno-format to affected components
2. disable the global option -Wno-format
3. fix format warnings for each component

component to the extra component list.

Signed-off-by: Felipe Neves [email protected]

Checklist

• [x] Component contains License
• [x] Component contains README.md
• [x] Component contains idf_component.yml file with url field defined
• [x] Component was added to upload job
• [x] Component was added to build job
• [ ] Optional: Component contains unit tests
• [ ] CI passing

Change description

Adds esp FoC vector controller for permanent magnet sychronous motors aka PMSM.

Checklist

• [x] Component contains License
• [x] Component contains README.md
• [x] Component contains idf_component.yml file with url field defined
• [x] Component was added to upload job
• [x] Component was added to build job
• [x] Optional: Component contains unit tests
• [x] CI passing

Change description

Moving USB host UVC class from IDF to esp-extra-components

Fixed build issue

On all chips except ESP32, essl_sdio.c should be able to be built. Theoratically ESSL should be able to make use of the SPI interface to communicate with ESP32 SDIO slave, even if the chip have no SDIO Slave interface.

• On ESP32-S3, there is no SDIO slave, but it can use SDMMC host to communicate with slave;
• On all chips, there is no SDIO slave, but ideally it can make use of SPI interface, though currently there is a bug with its timing.

Fix this issue.

Remove dependency to soc/host_reg.h

The host should work without depending on the private information of ESP32. Only the public part is necessary. Remove the dependency to (esp32)/soc/host_reg.h so that ESSL can be built, and be more portable.

Upgrade to v1.0.1

I think these can be treated as bugs.

Transfer timeout increased from 1 second to 5 seconds (as recommended in USB specs). Shorter timeout caused undesired behavior on some USB flash drives, such as re-connection issues: https://github.com/espressif/esp-idf/issues/9619

Move USB Host CDC driver to idf-extra-components

1. CDC driver copy pasted (with history) from esp-idf (including bugfix commit https://github.com/tore-espressif/esp-idf/commit/438234ad702fcd8ddc9781dcb2782f15a014d235)
2. Copy USB test_app to idf-extra-components

• [x] Change name of the uploaded package to usb_host_cdc_acm

• USB tests are not build/run in this PR yet
• Component uploaded to stagging server for testing https://staging.components.espressif.tools/component/espressif/usb_host_cdc_acm
• This component should then be used in https://github.com/espressif/esp-protocols/pull/25

One of the options to address https://github.com/espressif/idf-extra-components/issues/25.

1. https://github.com/espressif/clang-tidy-runner is used to run clang-tidy on the test app
2. Resulting warnings.txt file is converted to SARIF format using https://github.com/psastras/sarif-rs/tree/main/clang-tidy-sarif
3. At this point, the issues list contains also warnings reported for ESP-IDF source code. We use filter_sarif.py to include only issues reported for the source code from this repository. At the same time, we convert absolute paths to relative, which helps Github associate the issue with the file in the repository.
4. Resulting filtered SARIF file is uploaded to Github as Code Quality result.

Note that the CI job takes about 12 minutes to run. Not sure if it's okay to run it for PRs, or we should only run it for the master branch.

The results look as follows:

• open issues: https://github.com/igrr/idf-extra-components/security/code-scanning
• example if the file is in idf-extra-components repo: https://github.com/igrr/idf-extra-components/security/code-scanning/486
• example if the file is in a submodule: https://github.com/igrr/idf-extra-components/security/code-scanning/485
• analysis results for this PR: https://github.com/espressif/idf-extra-components/security/code-scanning?query=is%3Aopen+pr%3A28+

Future work: https://github.com/espressif/clang-tidy-runner/issues/7, https://github.com/espressif/clang-tidy-runner/issues/9

Checklist

• [x] Component contains License
• [x] Component contains README.md
• [x] Component contains idf_component.yml file with url field defined
• [x] Component was added to upload job
• [x] Component was added to build job
• [] Optional: Component contains unit tests
• [x] CI passing

Change description

• IDF versions below v5.0 already include the cbor component in source format.
• Due to this, there is a conflict if the cbor component is used on lower versions of IDF and the only way to fix it is by adding a rule to the idf_component.yml
• This commit sets the minimum version to IDF v5.0 to fix this behaviour.

…ough and safe

Checklist

• [ ] Component contains License
• [ ] Component contains README.md
• [ ] Component contains idf_component.yml file with url field defined
• [ ] Component was added to upload job
• [ ] Component was added to build job
• [ ] Optional: Component contains unit tests
• [ ] CI passing

Change description

It is unsafe to require the private key on encryption stage, just use public key.

as there is no Example for LED Strip, i made one:

https://gitlab.com/meisterschulen-am-ostbahnhof-munchen/esp32-4diac-example-application/-/tree/LEDRainbow/TestLEDStrip

Enjoy !

I am running examples/system/ota/pre_encrypted_ota/ with ESP-IDF: v5.0 esp_encrypted_img: v2.0.2

Since this is just a test for now, I have not changed the rsa_key/private.pem file.

HTTPS connection to the OTA server succeeds. Originally the download was failing to complete; it seems the server was closing the connection before all data was transferred. Here is example log output (at DEBUG log level):

D (53877) HTTP_CLIENT: need_read=512, byte_to_read=512, rlen=512, ridx=512
D (53887) HTTP_CLIENT: http_on_body 512
D (53897) esp_https_ota: Written image length 590336
D (53897) pre_encrypted_ota_example: Image bytes read: 590336
D (53907) HTTP_CLIENT: is_data_remain=1, is_chunked=0, content_length=932336
D (53937) HTTP_CLIENT: need_read=1024, byte_to_read=512, rlen=-1, ridx=0
W (53937) HTTP_CLIENT: esp_transport_read returned:-1 and errno:128 
D (53937) HTTP_CLIENT: Data processed 589824 != Data specified in content length 932336
E (53947) esp_https_ota: data read -1, errno 128
D (53947) HTTP_CLIENT: Data processed 589824 != Data specified in content length 932336
E (53957) pre_encrypted_ota_example: Complete data was not received.
E (53967) pre_encrypted_ota_example: ESP_HTTPS_OTA upgrade failed

Setting "Enable partial HTTP download" in SDK Configuration editor solved that problem & the full download of the binary completes.

But then esp_encrypted_img_decrypt_end() fails with ESP_FAIL (I have added an error log to the example code):

    if (!esp_https_ota_is_complete_data_received(https_ota_handle)) {
        // the OTA image was not completely received and user can customise the response to this situation.
        ESP_LOGE(TAG, "Complete data was not received.");
    } else {
        err = esp_encrypted_img_decrypt_end(decrypt_handle);
        if (err != ESP_OK) {
-->         ESP_LOGE(TAG, "esp_encrypted_img_decrypt_end() returned %d = %s", err, esp_err_to_name(err));
            goto ota_end;
        }

Below is the end of the log output (at DEBUG log level).

What is causing esp_encrypted_img to log the error Invalid operation?

I (135817) esp-x509-crt-bundle: Certificate validated
D (136637) HTTP_CLIENT: Write header[4]: GET /ota/pre_encrypted_ota_secure.bin HTTP/1.1
User-Agent: ESP32 HTTP Client/1.0
Host: myserver.net
Content-Length: 0
Range: bytes=918016-


D (136917) HTTP_CLIENT: on_message_begin
D (136917) HTTP_CLIENT: HEADER=Date:Sun, 18 Dec 2022 13:48:24 GMT
D (136917) HTTP_CLIENT: HEADER=Server:Apache
D (136917) HTTP_CLIENT: HEADER=Vary:IS_SUBREQ,User-Agent
D (136927) HTTP_CLIENT: HEADER=Upgrade:h2
D (136927) HTTP_CLIENT: HEADER=Connection:Upgrade
D (136927) HTTP_CLIENT: HEADER=Last-Modified:Sun, 18 Dec 2022 08:00:42 GMT
D (136937) HTTP_CLIENT: HEADER=ETag:"e39f0-5f0159970331c"
D (136947) HTTP_CLIENT: HEADER=Accept-Ranges:bytes
D (136947) HTTP_CLIENT: HEADER=Content-Length:14320
D (136957) HTTP_CLIENT: HEADER=Cache-Control:max-age=172800
D (136957) HTTP_CLIENT: HEADER=Expires:Tue, 20 Dec 2022 13:48:24 GMT
D (136967) HTTP_CLIENT: HEADER=Content-Range:bytes 918016-932335/932336
D (136977) HTTP_CLIENT: HEADER=Content-Type:application/octet-stream
D (136977) HTTP_CLIENT: http_on_headers_complete, status=206, offset=421, nread=421
D (136987) HTTP_CLIENT: content_length = 14320
D (136987) esp_https_ota: Connection start
D (136997) pre_encrypted_ota_example: Image bytes read: 918016
D (136997) HTTP_CLIENT: is_data_remain=1, is_chunked=0, content_length=14320
D (137037) HTTP_CLIENT: need_read=1024, byte_to_read=512, rlen=512, ridx=0
D (137037) HTTP_CLIENT: http_on_body 512
D (137037) HTTP_CLIENT: is_data_remain=1, is_chunked=0, content_length=14320
D (137047) transport_base: remain data in cache, need to read again
D (137047) HTTP_CLIENT: need_read=512, byte_to_read=512, rlen=512, ridx=512
D (137057) HTTP_CLIENT: http_on_body 512
D (137107) esp_https_ota: Written image length 919040
D (137107) pre_encrypted_ota_example: Image bytes read: 919040
D (137107) HTTP_CLIENT: is_data_remain=1, is_chunked=0, content_length=14320
D (137117) transport_base: remain data in cache, need to read again
( ... etc ...)
D (138007) HTTP_CLIENT: need_read=1024, byte_to_read=512, rlen=512, ridx=0
D (138017) HTTP_CLIENT: http_on_body 512
D (138017) HTTP_CLIENT: is_data_remain=1, is_chunked=0, content_length=14320
D (138027) transport_base: remain data in cache, need to read again
D (138037) HTTP_CLIENT: need_read=512, byte_to_read=512, rlen=496, ridx=512
D (138037) HTTP_CLIENT: http_on_body 496
D (138047) HTTP_CLIENT: http_on_message_complete, parser=3ffbe5d0
D (138047) HTTP_CLIENT: is_data_remain=0, is_chunked=0, content_length=14320
D (138067) esp_https_ota: Written image length 932336
D (138067) pre_encrypted_ota_example: Image bytes read: 932336
D (138067) HTTP_CLIENT: is_data_remain=0, is_chunked=0, content_length=14320
D (138077) esp_https_ota: Connection closed
E (138077) esp_encrypted_img: Invalid operation
E (138087) pre_encrypted_ota_example: esp_encrypted_img_decrypt_end() returned -1 = ESP_FAIL
E (138097) pre_encrypted_ota_example: ESP_HTTPS_OTA upgrade failed

Checklist

• [x ] Component contains License
• [ x] Component contains README.md
• [ x] Component contains idf_component.yml file with url field defined
• [ x] Component was added to upload job
• [x ] Component was added to build job
• [ ] Optional: Component contains unit tests
• [ ] CI passing

Change description

This PR add example to the Eigen component directory that shows how to use the eigen library and IDF Eigen component.

Regards, Dmitry