cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

KEKA_4568351
Contributor

■内部フラッシュの書き込み中(DCT Write)に、UART(GPIO)のデータ通信(受信)ができない

  UART (GPIO) data communication (reception) cannot be performed while writing to the internal flash (DCT Write)

<Japanese>

内部フラッシュの書き込み中(DCT Write)に、UART(GPIO)のデータ通信(受信)が重なると、受信ができないことがあります。

この現象について、わかる方がいたら、メッセージお願いします。

UART:GPIO使用

DCT:wiced_dct_write (内部)

<English>

If data communication (reception) of UART (GPIO) overlaps during writing of internal flash (DCT Write), reception may not be possible.

If you can understand this phenomenon, please give me a message.

UART: using GPIO

DCT: wiced_dct_write (internal)

0 Likes
1 Solution
KEKA_4568351
Contributor

The underlying cause is unknown, but it is probably due to the phenomenon that the receive interrupt stops in the platform_uart_rx_dma_irq API. (Interrupts are unknown because WWD_RTOS_DEFINE_ISR, _tx_timer_interrupt, and ThreadX internals are unknown.)

Avoided by resetting with wiced_uart_deinit and wiced_uart_init.

<Japanese>

根本的な原因は不明ですが、platform_uart_rx_dma_irq APIで、受信割込みが停止する現象のためと思われます。

(割込みは、WWD_RTOS_DEFINE_ISR、_tx_timer_interrupt、ThreadX内部はソースがなく不明なため、原因解析不可)

wiced_uart_deinit、wiced_uart_initによる、リセットにより回避した。

View solution in original post

0 Likes
8 Replies
KEKA_4568351
Contributor

Thank you very much.

The platform uses the STM32F4xx family.

【MAKE】

WLAN_CHIP: = 4343W

WLAN_CHIP_REVISION: = A1

WLAN_CHIP_FAMILY: = 4343x

HOST_MCU_FAMILY: = STM32F4xx

HOST_MCU_VARIANT: = STM32F412

HOST_MCU_PART_NUMBER: = STM32F412RGY6

BT_CHIP: = 43438

BT_CHIP_REVISION: = A1

BT_CHIP_XTAL_FREQUENCY: = 26MHz

PLATFORM_SUPPORTS_BUTTONS: = 1

0 Likes
RaktimR_11
Moderator
Moderator

Please use two threads, one for DCT and the other one for UART R/W, and you can use some thread signaling mechanism to signal in-between threads.

KEKA_4568351
Contributor

UART and DCT Write are processed by separate threads.

0 Likes
RaktimR_11
Moderator
Moderator

In that case, I am not sure about the ask here. If UART and DCT write are processed by separate threads, are you seeing any issue in your application?

KEKA_4568351
Contributor

Yes, the phenomenon occurs when DCT writing and UART reception processing overlap.

0 Likes
RaktimR_11
Moderator
Moderator

Can you provide a log for this phenomenon? (Say you are missing some uart bytes when the processes are overlapping)

Ideally, you can use some thread signalling mechanism, like semaphore, mutex, queues to protect the overlap such that nothing is missed. Based on the criticality of each operation, you can use different priority threads as well instead of relying on time-slicing.

If you want, I can share my code which seems to be working fine without missing anything but I am guessing you are trying to achieve something different in your application. If yes, kindly share that for us to understand the issue clearly and redress the same.

KEKA_4568351
Contributor

The underlying cause is unknown, but it is probably due to the phenomenon that the receive interrupt stops in the platform_uart_rx_dma_irq API. (Interrupts are unknown because WWD_RTOS_DEFINE_ISR, _tx_timer_interrupt, and ThreadX internals are unknown.)

Avoided by resetting with wiced_uart_deinit and wiced_uart_init.

<Japanese>

根本的な原因は不明ですが、platform_uart_rx_dma_irq APIで、受信割込みが停止する現象のためと思われます。

(割込みは、WWD_RTOS_DEFINE_ISR、_tx_timer_interrupt、ThreadX内部はソースがなく不明なため、原因解析不可)

wiced_uart_deinit、wiced_uart_initによる、リセットにより回避した。

View solution in original post

0 Likes