- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
■内部フラッシュの書き込み中(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)
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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による、リセットにより回避した。
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is the platform you are using?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
UART and DCT Write are processed by separate threads.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, the phenomenon occurs when DCT writing and UART reception processing overlap.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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による、リセットにより回避した。