Strange 41.5ms Pulse when using RMT (IDFGH-7931)

[diplfranzhoepfinger]

Environment

• Development Kit: [ESP32-DevKitC]
• Kit version (for WroverKit/PicoKit/DevKitC): [v4]
• Module or chip used: [ESP32-S3]
• IDF version (run git describe --tags to find it):
  v5.0-dev-4379-g36f49f361c
• Build System: [CMake|idf.py]
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  xtensa-esp32-elf-gcc (crosstool-NG esp-2022r1-RC1) 11.2.0
• Operating System: [Linux]
• Power Supply: [USB]

Problem Description

i want to issue 5 Pulses of 500 µs ...

there is a pullup in Place.

the 5 Pulses are generated precisely, but in Front of the 5 500 µs Impulses there is a 41.5ms Pulse.

all pulses are negative Pulses; this should be. open-drain mode is set.

Expected Behavior

JUST the 5 Pulses. no Starting 41.5ms Pulse.

Steps to reproduce

// If possible, attach a picture of your setup/wiring here.

Code to reproduce this issue

https://gist.github.com/diplfranzhoepfinger/138598910c9c6aa02ee7579ab2a34718

[diplfranzhoepfinger]

same SW on a ESP32 it is a 23.87ms Pulse.

[suda-morris]

I'm afraid what you mean the "strange pulse" is the timing slot between rmt_enable and rmt_transmit.

My test code:

#include <stdio.h>
#include "sdkconfig.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/rmt_tx.h"

#define RMT_TPMS_RESOLUTION_HZ 1000000 // 1MHz resolution, 1 tick = 1us
#define RMT_TPMS_GPIO_NUM      0

void app_main(void)
{
    rmt_channel_handle_t tx_channel = NULL;
    // create rmt tx channel after rx channel
    rmt_tx_channel_config_t tx_chan_config = {
        .clk_src = RMT_CLK_SRC_DEFAULT,
        .gpio_num = RMT_TPMS_GPIO_NUM,
        .mem_block_symbols = 64,
        .resolution_hz = RMT_TPMS_RESOLUTION_HZ,
        .trans_queue_depth = 4,
        .flags.io_od_mode = true,
    };
    ESP_ERROR_CHECK(rmt_new_tx_channel(&tx_chan_config, &tx_channel));

    rmt_encoder_handle_t copy_encoder = NULL;
    rmt_copy_encoder_config_t copy_encoder_config = {};
    ESP_ERROR_CHECK(rmt_new_copy_encoder(&copy_encoder_config, &copy_encoder));

    ESP_ERROR_CHECK(rmt_enable(tx_channel));

    const static rmt_transmit_config_t tx_config = {
        .loop_count = 5,
        .flags.eot_level = 1,
    };
    const static rmt_symbol_word_t rmt_test_symbol = {
        .level0 = 1,
        .duration0 = 500,
        .level1 = 0,
        .duration1 = 500,
    };

    ESP_ERROR_CHECK(rmt_transmit(tx_channel, copy_encoder, &rmt_test_symbol, sizeof(rmt_test_symbol), &tx_config));
}

[diplfranzhoepfinger]

YES. Questions: can it be avoided ? it would be sufficient to have the Pin floating, so not pulling down for a Open-Drain output. Am Do., 28. Juli 2022 um 09:36 Uhr schrieb suda-morris < ***@***.***>:

…

I'm afraid what you mean the "strange pulse" is the timing slot between rmt_enable and rmt_transmit. [image: image] <https://user-images.githubusercontent.com/8869469/181448229-b608945f-aaa2-4f06-88f6-7dacaaed6352.png> My test code: #include <stdio.h> #include "sdkconfig.h" #include "freertos/FreeRTOS.h" #include "freertos/task.h" #include "driver/rmt_tx.h" #define RMT_TPMS_RESOLUTION_HZ 1000000 // 1MHz resolution, 1 tick = 1us #define RMT_TPMS_GPIO_NUM 0 void app_main(void) { rmt_channel_handle_t tx_channel = NULL; // create rmt tx channel after rx channel rmt_tx_channel_config_t tx_chan_config = { .clk_src = RMT_CLK_SRC_DEFAULT, .gpio_num = RMT_TPMS_GPIO_NUM, .mem_block_symbols = 64, .resolution_hz = RMT_TPMS_RESOLUTION_HZ, .trans_queue_depth = 4, .flags.io_od_mode = true, }; ESP_ERROR_CHECK(rmt_new_tx_channel(&tx_chan_config, &tx_channel)); rmt_encoder_handle_t copy_encoder = NULL; rmt_copy_encoder_config_t copy_encoder_config = {}; ESP_ERROR_CHECK(rmt_new_copy_encoder(&copy_encoder_config, &copy_encoder)); ESP_ERROR_CHECK(rmt_enable(tx_channel)); const static rmt_transmit_config_t tx_config = { .loop_count = 5, .flags.eot_level = 1, }; const static rmt_symbol_word_t rmt_test_symbol = { .level0 = 1, .duration0 = 500, .level1 = 0, .duration1 = 500, }; ESP_ERROR_CHECK(rmt_transmit(tx_channel, copy_encoder, &rmt_test_symbol, sizeof(rmt_test_symbol), &tx_config)); } — Reply to this email directly, view it on GitHub <#9449 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJAHMXNB2M6O4BZD6WH3SLDVWIZ7TANCNFSM543C5ESQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Diplom-Informatiker Franz Höpfinger e.K. Reibersdorf 16a 84419 Schwindegg

[suda-morris]

I'm afraid no. The default level of RMT TX signal (before transmitting any RMT symbol) is zero, which is not controllable AFAIK.

[franz-ms-muc]

Btw. Which logic analyzer do you use? I want to buy one as oscilloscope is not always helpful for such Signals.

[suda-morris]

Btw. Which logic analyzer do you use? I want to buy one as oscilloscope is not always helpful for such Signals.

Either dsview or pulseview should work

[suda-morris]

I'm afraid no. The default level of RMT TX signal (before transmitting any RMT symbol) is zero, which is not controllable AFAIK.

Yeap, this has been confirmed by our digital team, the default level (default means before sending the first RMT symbol) is always zero, and it's not controllable. I will close this issue for now, feel free to reopen or recreate a new one if you find other weird hardware/software behaviors.