uart_configure cause Stack overflow

when the code run to "uart_configure" function, the program cause Stack overflow 

	if (mdata.current_serial_speed != MDM_SPEED_WORK)
	{
		if (serial_cfg.baudrate != mdata.current_serial_speed)
		{
			serial_cfg.baudrate = mdata.current_serial_speed;
			// 停止接收数据
			uart_irq_rx_disable(MDM_UART_DEV);

			uart_configure(MDM_UART_DEV, &serial_cfg);
			// 开启接收数据
			uart_irq_rx_enable(MDM_UART_DEV);
		}

		snprintk(buf, sizeof(buf), "AT+IPR=%u", MDM_SPEED_WORK);

		ret = modem_cmd_send(&mctx.iface, &mctx.cmd_handler, NULL, 0U, buf,
							 &mdata.sem_response, K_MSEC(500));
		if (ret < 0)
		{
			LOG_ERR("Failed to send init commands!");
			goto error;
		}
		mdata.current_serial_speed = MDM_SPEED_WORK;
		serial_cfg.baudrate = MDM_SPEED_WORK;


		// 停止接收数据
		uart_irq_rx_disable(MDM_UART_DEV);

		uart_configure(MDM_UART_DEV, &serial_cfg);
		// 开启接收数据
		uart_irq_rx_enable(MDM_UART_DEV);

	}

Parents
  • Hi,

    1. Increasing the stacksize on the thread that triggers the overflow should remove this error
    2. One tip is also to name your threads, if you haven't done so already. From the log it is currently called "Unknown". See https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-7-multithreaded-applications/topic/exercise-1-7/ for more

    Kind regards,
    Andreas

  • this code is called by startup, here is below

    modem_init->modem_setup->uart_configure
    what stack should be configured in this case?
  • Hi,

    1. Does the thread definition contain any parameters related to the stack size similar to the following?
    2. Did you have a look at prj.conf in the links I sent you to see if you were able to spot how it's done there? Here's the github link https://github.com/NordicDeveloperAcademy/ncs-fund/tree/main/v2.x.x/lesson7 
    3. If neither of these two are correct, you can use the Kconfig search with the term 'stack_size' to check if there are any configurations you're missing?
    4. Could you also provide me your prj.conf?

    Kind regards,
    Andreas

  • I've seen the link you sent, I've also tried increasing the stack size in prj.conf, but stack overflow still happens.

    After debugging, it was found that a stack overflow occurs whenever the “uart_configure (mctx.iface.dev, &serial_cfg)”  be called.After looking at the memory address, it looks like a stack overflow that occurred on the idle thread.

    CONFIG_BT=y
    CONFIG_BT_PERIPHERAL=y
    CONFIG_BT_DEVICE_NAME="MS6KY"
    
    CONFIG_BT_SMP=y
    CONFIG_BT_FIXED_PASSKEY=y
    
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
    CONFIG_LOG=y
    CONFIG_LOG_PRINTK=y
    CONFIG_LOG_MODE_IMMEDIATE=y
    CONFIG_UART_CONSOLE=y
    
    CONFIG_CMSIS_DSP=y
    CONFIG_FPU=y
    CONFIG_CMSIS_DSP_STATISTICS=y
    CONFIG_NEWLIB_LIBC=y
    CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
    
    CONFIG_JSON_LIBRARY=y
    
    CONFIG_HEAP_MEM_POOL_SIZE=8192
    CONFIG_SIMCOM_A7670C_DRIVER=y
    CONFIG_MODEM_SIM_NUMBERS=y
    CONFIG_MODEM_SIMCOM_A7670C_RX_STACK_SIZE=2048
    CONFIG_NET_BUF=y
    CONFIG_NTP_SERVER_ADDR="121.229.25.208"
    
    
    CONFIG_NRFX_SAADC=y
    CONFIG_NRFX_TIMER1=y
    
    CONFIG_DATE_TIME=y
    
    CONFIG_DEBUG_THREAD_INFO=n
    
    CONFIG_DATE_TIME_NTP=n
    # CONFIG_NETWORKING=n
    # CONFIG_SDMMC_LOG_LEVEL_DBG=y
    
    CONFIG_MAIN_STACK_SIZE=16384
    
    
    
    CONFIG_FILE_SYSTEM=y
    CONFIG_FAT_FILESYSTEM_ELM=y
    CONFIG_FS_FATFS_LFN=y
    CONFIG_DISK_DRIVER_SDMMC=y
    
    
    CONFIG_PM=y
    CONFIG_PM_DEVICE=y
    CONFIG_PM_DEVICE_POWER_DOMAIN=y
    
    CONFIG_MODBUS=y
    CONFIG_MODBUS_ROLE_CLIENT=y
    
    CONFIG_MODBUS_LOG_LEVEL_DBG=n
    
    
    CONFIG_UART_INTERRUPT_DRIVEN=y
    CONFIG_UART_LINE_CTRL=y
    
    
    CONFIG_SETTINGS=y
    CONFIG_NVS=y
    CONFIG_FLASH=y
    CONFIG_FLASH_PAGE_LAYOUT=y
    CONFIG_FLASH_MAP=y
    CONFIG_SETTINGS_NVS=y
    
    CONFIG_SETTINGS=y
    CONFIG_SETTINGS_RUNTIME=y
    
    
    # CONFIG_RING_BUFFER=y
    
    # CONFIG_DATA_CACHE_SIZE=16
    
    
    CONFIG_LOG_USER_SETTINGS_LEVEL=0
    # CONFIG_LOG_MAIN_LEVEL=3
    CONFIG_NVS_LOG_LEVEL_OFF=y
    CONFIG_SD_LOG_LEVEL_OFF=y
    
    CONFIG_UART_USE_RUNTIME_CONFIGURE=y
    
    
    
    
    

  • Hi,

    Does the overflow occur when you have a main stack size of 16384? If so then I suspect you have a memory leak somewhere in your firmware unless it is related to having heap or workqueue stack size set too small. I see they are 8192, which should also be more than sufficient. 

    Could you explain more about exactly what your application should do since you have set these sizes so large?

    Kind regards,
    Andreas

Reply
  • Hi,

    Does the overflow occur when you have a main stack size of 16384? If so then I suspect you have a memory leak somewhere in your firmware unless it is related to having heap or workqueue stack size set too small. I see they are 8192, which should also be more than sufficient. 

    Could you explain more about exactly what your application should do since you have set these sizes so large?

    Kind regards,
    Andreas

Children
  • I've also tried increasing the size of the main stack, and I have also tried increasing the size of the workqueue stack, and the same phenomenon still occurs. I think it should not be a problem with the stack, or a stack overflow when changing the baud rate from 115200 to 230400 at runtime, as long as the baud rate is not modified, there is no problem

  • Noted,

    it looks like a stack overflow that occurred on the idle thread.

    Did you increase the stack size of the idle thread?

    or a stack overflow when changing the baud rate from 115200 to 230400 at runtime, as long as the baud rate is not modified, there is no problem

    This sounds strange. Changing the baud rate on runtime should not lead to a stack overflow, unless there is something in Zephyr that also changes when you change the baud rate during runtime such as buffers increasing in size or similar items. Or  that you do additional modifications at the same time that you change the baud rate. I would recommend you to investigate these two items when debugging further

    Kind regards,
    Andreas

Related