RS485 Enable pin issue

ESP_alisitsyn
Posts: 203
Joined: Fri Feb 01, 2019 4:02 pm
Contact:

Re: RS485 Enable pin issue

Postby ESP_alisitsyn » Wed Jul 21, 2021 9:53 am

I just need to set this in the menuconfig and not do anything else in code and not use the tx_done check right?
Yes. It can be acceptable for your code to check. Please try to reproduce the issue with the handler in IRAM and the patch applied.
Please use the `git apply --check patch_name.diff` to check that patch applied correctly for your ESP-IDF v4.3

I see you can do same for TWAI (which I use in another project) do you usually want TWAI int in IRAM also?)
Yes. You can do it (TWAI_ISR_IN_IRAM) in your project where you use the TWAI. This depends on what other IDF components you are using.

sramberg2
Posts: 9
Joined: Tue Jul 20, 2021 9:35 pm

Re: RS485 Enable pin issue

Postby sramberg2 » Wed Jul 21, 2021 7:01 pm

No luck. Applied the changes to uart.c and moved the ISR to IRAM and it still fails.

orbitcoms
Posts: 141
Joined: Fri Aug 03, 2018 10:08 pm
Location: Sydney, Australia

Re: RS485 Enable pin issue

Postby orbitcoms » Wed Jul 21, 2021 9:02 pm

I am having trouble applying the patch. Should I be renaming the extension from txt to something else?

Saved git apply 0001_driver_uart_fix_rts_assertion_issue.diff.txt to folder

ran git apply 0001_driver_uart_fix_rts_assertion_issue.diff from command prompt.

Get error no such file or directory

Thanks

ESP_alisitsyn
Posts: 203
Joined: Fri Feb 01, 2019 4:02 pm
Contact:

Re: RS485 Enable pin issue

Postby ESP_alisitsyn » Thu Jul 22, 2021 8:37 am

@orbitcoms, @sramberg2,

Thank you for your contribution. I need to ask you to follow the instruction below to get reproducible results:
1. execute the next commands in your terminal:

Code: Select all

cd $IDF_PATH
git fetch origin
git checkout origin/release/v4.3 -f
git submodule update --init --recursive
git log -n 2
2. then send me the output of the command

Code: Select all

git log -n 2

following with the log of below command (if exists)

Code: Select all

git apply --check 0001_driver_uart_fix_rts_assertion_issue.diff.txt
then apply actual changes from patch to the files

Code: Select all

git apply 0001_driver_uart_fix_rts_assertion_issue.diff.txt
3. Compile your project which has the issue.

Code: Select all

cd `your_proj_name_folder`
idf.py build
4. Also I would ask you to create the example project and following folders structure inside:

Code: Select all

[your_proj_name_folder]
|------[components]
         |------[driver] < copy your esp-idf/components/driver folder here
         |------[freemodbus] < copy your esp-idf/components/freemodbus folder here
Then please create zip archive of your`your_proj_name_folder`. The folder shall include sdkconfig, the required artifacts to build project. The build artifacts shall include `your_proj_name_folder/build/*.map, *.bin, *.elf` files. Please also include into zip the logs for commands above. This zip will help to reproduce and solve issue on my side.
Thanks.

sramberg2
Posts: 9
Joined: Tue Jul 20, 2021 9:35 pm

Re: RS485 Enable pin issue

Postby sramberg2 » Thu Jul 22, 2021 3:55 pm

I switched to using uart_tx_chars() and I still had the failure.
Since I am only sending 7 bytes at a time and not very often, at least 10ms between transmits, I modified uart_tx_chars() to move the critical section to include the call to uart_hal_write_txfifo(). The issue did not occur overnight. This is not a great long term fix but hopefully this will point to something.
  1. int uart_tx_chars(uart_port_t uart_num, const char* buffer, uint32_t len)
  2. {
  3.     UART_CHECK((uart_num < UART_NUM_MAX), "uart_num error", (-1));
  4.     UART_CHECK((p_uart_obj[uart_num]), "uart driver error", (-1));
  5.     UART_CHECK(buffer, "buffer null", (-1));
  6.     if(len == 0) {
  7.         return 0;
  8.     }
  9.     int tx_len = 0;
  10.     xSemaphoreTake(p_uart_obj[uart_num]->tx_mux, (portTickType)portMAX_DELAY);
  11.     UART_ENTER_CRITICAL(&(uart_context[uart_num].spinlock));
  12.     if (UART_IS_MODE_SET(uart_num, UART_MODE_RS485_HALF_DUPLEX)) {
  13.         uart_hal_clr_intsts_mask(&(uart_context[uart_num].hal), UART_INTR_TX_DONE);
  14.         uart_hal_set_rts(&(uart_context[uart_num].hal), 0);
  15.         uart_hal_ena_intr_mask(&(uart_context[uart_num].hal), UART_INTR_TX_DONE);
  16.     }
  17.     uart_hal_write_txfifo(&(uart_context[uart_num].hal), (const uint8_t*) buffer, len, (uint32_t *)&tx_len);
  18.     UART_EXIT_CRITICAL(&(uart_context[uart_num].spinlock));
  19.     xSemaphoreGive(p_uart_obj[uart_num]->tx_mux);
  20.     return tx_len;
  21. }

ESP_alisitsyn
Posts: 203
Joined: Fri Feb 01, 2019 4:02 pm
Contact:

Re: RS485 Enable pin issue

Postby ESP_alisitsyn » Fri Jul 23, 2021 6:30 am

@sramberg2,

This is exactly what I was thinking of and tried to check yesterday.
Task1 - is the sending task;
Task2 - some other task with higher priority;
Task1 calls uart_tx_all() when and tx ring buffer is not used.

1. Task1 sets the RTS line and enables the TX_DONE;
2. Task2 with higher priority is activated, Task1 suspended before write UART FIFO;
3. The pending TX_DONE interrupt occured and clears RTS state back to zero;
4. The Task1 goes to run state and continued to write FIFO;
5. UART transmission is continued but RTS is in LOW state;

The issue happens only if the step 2 exists this is why it is very rare;

uart_hal_write_txfifo() just fills the FIFO using register area and it can be called from the critical section.

sramberg2
Posts: 9
Joined: Tue Jul 20, 2021 9:35 pm

Re: RS485 Enable pin issue

Postby sramberg2 » Fri Jul 23, 2021 5:23 pm

Your analysis matches my system. Thank you.

ESP_alisitsyn
Posts: 203
Joined: Fri Feb 01, 2019 4:02 pm
Contact:

Re: RS485 Enable pin issue

Postby ESP_alisitsyn » Mon Jul 26, 2021 11:05 am

@sramberg2,

Let us consider the workaround you proposed as current simple fix for now. The uart_hal_write_txfifo() will be called from within critical section that will block the interrupt during fifo writing. The write of FIFO is finit operation but takes relatively long time under critical section and this is price of this workaround. The issue will follow the formal process and this will take some time.

Let me know if you have other concerns.

Thank you.

Who is online

Users browsing this forum: Baidu [Spider], Bing [Bot], HighVoltage and 117 guests