January 19, 2018 at 11:34 #13524
I’m running the RTOS Http Demo for the ESP8266, using a Segger J-Link to debug.
uart.h includes a uart_init_new() function, which I am calling in user_init(). As far as I can tell, this is all that should be necessary to then have printf() calls logged in the UART output.
I do have some UART output (even without calling uart_init_new()), as far as I can tell, as logged by VisGDB:C++123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960c:\sysgcc\esp8266\esp8266-bsp\OpenOCD\bin\openocd.exe -c "gdb_port 53681" -c "telnet_port 53682" -f interface/jlink.cfg -f target/esp8266.cfg -c "adapter_khz 3000" -c "echo VisualGDB_OpenOCD_Ready"Open On-Chip Debugger 0.9.0 (2015-11-04-20:38)Licensed under GNU GPL v2For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmltrst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srstadapter speed: 1000 kHzstop_wdtadapter speed: 3000 kHzVisualGDB_OpenOCD_ReadyInfo : J-Link V10 compiled Jan 11 2018 10:41:05Info : J-Link caps 0xb9ff7bbfInfo : J-Link hw version 101000Info : J-Link hw type J-LinkInfo : J-Link max mem block 14576Info : J-Link configurationInfo : USB-Address: 0x0Info : Kickstart power on JTAG-pin 19: 0xffffffffInfo : Vref = 3.367 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1Info : J-Link JTAG Interface readyInfo : clock speed 3000 kHzInfo : TAP esp8266.cpu does not have IDCODEInfo : halted: PC: 0x4010278eInfo : debug cause: 0x20Info : accepting 'gdb' connection on tcp/53681Info : TAP esp8266.cpu does not have IDCODEWarn : xtensa_poll: DOSR has set InOCDMode without the Exception flag. Unexpected. DOSR=0x04target state: haltedInfo : halted: PC: 0x4010278eInfo : debug cause: 0x20Warn : xtensa_deassert_reset: 'reset halt' is not supported for Xtensa. Have halted some time after resetting (not the same thing!)Info : TAP esp8266.cpu does not have IDCODEWarn : xtensa_poll: DOSR has set InOCDMode without the Exception flag. Unexpected. DOSR=0x04target state: haltedInfo : halted: PC: 0x4010278eInfo : debug cause: 0x20Warn : xtensa_deassert_reset: 'reset halt' is not supported for Xtensa. Have halted some time after resetting (not the same thing!)Info : halted: PC: 0x40102791Info : debug cause: 0x1Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Info : halted: PC: 0x4010013cInfo : debug cause: 0x8Interrupt suppression during single-stepping is now enabledWatchdog feeding during stops is now enabledInfo : halted: PC: 0x40100004Info : debug cause: 0x2
Does this mean the UART connection is working, but printf() somehow isn’t being logged there?
I have left uart_init_new() as implemented by default:C++123456789101112131415161718192021222324UART_WaitTxFifoEmpty(UART0);UART_WaitTxFifoEmpty(UART1);UART_ConfigTypeDef uart_config;uart_config.baud_rate = BIT_RATE_74880;uart_config.data_bits = UART_WordLength_8b;uart_config.parity = USART_Parity_None;uart_config.stop_bits = USART_StopBits_1;uart_config.flow_ctrl = USART_HardwareFlowControl_None;uart_config.UART_RxFlowThresh = 120;uart_config.UART_InverseMask = UART_None_Inverse;UART_ParamConfig(UART0, &uart_config);UART_IntrConfTypeDef uart_intr;uart_intr.UART_IntrEnMask = UART_RXFIFO_TOUT_INT_ENA | UART_FRM_ERR_INT_ENA | UART_RXFIFO_FULL_INT_ENA | UART_TXFIFO_EMPTY_INT_ENA;uart_intr.UART_RX_FifoFullIntrThresh = 10;uart_intr.UART_RX_TimeOutIntrThresh = 2;uart_intr.UART_TX_FifoEmptyIntrThresh = 20;UART_IntrConfig(UART0, &uart_intr);UART_SetPrintPort(UART0);UART_intr_handler_register(uart0_rx_intr_handler, NULL);ETS_UART_INTR_ENABLE();
Any advice on how to get logging to work properly?January 20, 2018 at 06:20 #13526
The “Info : debug cause: 0x8” and other similar messages come from OpenOCD – the command line tool used for debugging; it is not directly related to the UART port output.
In order to see the UART output from esp8266, you would need to physically connect a USB-to-UART adapter to the UART pins on your module (please ensure you use a level translator, as UART and regular CMOS logic use different voltages and connecting them directly might burn one side). Once you connect it, you can see the UART output in the corresponding COM port (either via VisualGDB’s Embedded Terminal or using our free SmarTTY tool).January 22, 2018 at 12:58 #13542
Thank you for the advice. I have now connected a USB-to-UART cable to my ESP8266 (alongside the Segger J-Link), and succeeded in opening a raw terminal for the COM port.
I am receiving output on the COM port, but a lot more than the simple printf(“test”); that I am expecting, and it is all garbled (including the “test”).
I have experimented with a few of the settings, mostly baud rate, which I think should be set to 74880. This value is also what the uart_config is set to in uart_init_new() (see OP).
However, I have noticed that it works seemingly identically without calling uart_init_new(), so I am unsure whether this is necessary or what it is good for.
My output looks like this before my call to printf():
Printing “test” adds
I doubt the garbled output will be helpful in helping you determine what might be going wrong, but do you have any suggestions as to what I could check/try?
January 22, 2018 at 13:51 #13544
- This reply was modified 2 years, 1 month ago by TvdVen.
I can’t seem to edit my previous post anymore, but I seem to have stumbled upon the fix since then. Changing the default baud rate of 74880 in the uart_init_new() function to 115200 and setting the COM port baud rate to that same value has resulted in legible output. Thank you for the assistance!January 23, 2018 at 07:00 #13555
Good to know it works. If you encounter further issues, don’t hesitate to create another topic.
You must be logged in to reply to this topic.