52840 NCS UART DFU

Hi

 I am currently working with my project with 52840 and i am using sdk v3.0.1 & toolchain v3.0.0 to develope.

 I am learning how to use DFU over UART from the application in Devacademy l9/e2 , it works fine using the example , after that i try it on my own project but because my project use one uart only , so UART DFU and my APP use the same uart(UART0) , and i added two config

CONFIG_SHELL=y
CONFIG_MCUMGR_TRANSPORT_SHELL=y

also init uart0 in my application 

void uart0_init(void)
{
    uint32_t err =  device_is_ready( dev_uart0 );

    if( err != true )
    {
        printk("\nUART_init_err = %d\n", err);
    }
    uart_irq_callback_user_data_set(dev_uart0,uart0_irq_callback, NULL )
   
    uart_irq_rx_enable( dev_uart0 );
}
i use Auterm(v0.35a) to Get image , Auterm data keep running into my uart0_irq_callback , not into MCUMGR shell
is there any way to let my application uart and uart dfu use the same uart and the same time without deinit the uart ? Thanks!
Parents
  • Hello,

    Sorry for the delayed response. Were you able to resolve the issue? If you're still experiencing problems, please share a minimal project with me. I will try to run it on the DK and attempt to reproduce the issue.

    I'm not entirely sure what exactly is going wrong, but it’s possible that when you enable CONFIG_MCUMGR_TRANSPORT_UART=y, MCUmanager sets up the UART and installs its own interrupt handler early during boot. If the application later sets its own UART IRQ handler using uart_irq_callback_user_data_set(), it may override the one used by MCUmanager. Since MCUmanager may not be aware that its handler was replaced, it doesn't regain control of the UART. Simply removing the application's handler might not bring DFU back. It may only start working again if you manually forward the UART data to MCUmanager or reboot the device.

    Kind regards,
    Abhijith

Reply
  • Hello,

    Sorry for the delayed response. Were you able to resolve the issue? If you're still experiencing problems, please share a minimal project with me. I will try to run it on the DK and attempt to reproduce the issue.

    I'm not entirely sure what exactly is going wrong, but it’s possible that when you enable CONFIG_MCUMGR_TRANSPORT_UART=y, MCUmanager sets up the UART and installs its own interrupt handler early during boot. If the application later sets its own UART IRQ handler using uart_irq_callback_user_data_set(), it may override the one used by MCUmanager. Since MCUmanager may not be aware that its handler was replaced, it doesn't regain control of the UART. Simply removing the application's handler might not bring DFU back. It may only start working again if you manually forward the UART data to MCUmanager or reboot the device.

    Kind regards,
    Abhijith

Children
No Data
Related