-->
Page 1 of 1

SDK 1.4 Example Code - Garbage on serial port.

PostPosted: Wed Sep 30, 2015 1:19 pm
by spacejunkie
Here's how I have setup my toolchain:

OS For Compiling: Ubuntu (VirtualBox Guest)
OS For Flashing: Windows 7 (VirtualBox Host)
Compiler: esp-open-sdk from https://github.com/pfalcon/esp-open-sdk
SDK: ESP SDK 1.4 from bbs.espressif.com

I have set the SDK_PATH to official Espressif SDK 1.4 and BIN_PATH to some other directory
In SDK 1.4, once you run gen_misc.sh it asks you to check SDK _PATH and BIN_PATH.
They show up with correct values.

Then I choose the appropriate values for the next set of questions (SPI Mode, Flash Config, Boot type etc.)
(I later use the same settings in the flash program.)

The process completes without any error and bin files are generated.
It even tells which address to burn each file to.

After burning the files to flash, all I get is garbage data on serial port. I have tried all standard baud rates. Same result.

FYI, I have tried the "project_template" and "smart_config" programs in examples directory of SDK1.4
Both have printf statements in the initialization portion so I was expecting to see some proper text on serial output.
But all I get is garbage characters.

The boards are fine. I have tried it on Node MCU board and Offical Espressif ESP_IOT Ref. board. Old firmware bin created on SDK0.9 and NodeMCU firmware bin run properly on both boards.

What could the problem be?

Re: SDK 1.4 Example Code - Garbage on serial port.

PostPosted: Wed Sep 30, 2015 7:25 pm
by lakid
I cooked one of my boards with excessive voltage and it did this...got a different one to test with ?

Re: SDK 1.4 Example Code - Garbage on serial port.

PostPosted: Thu Oct 01, 2015 1:43 am
by spacejunkie
There were two problems:

1. I was selecting QIO as it was the default. I used the same setting while compiling and flashing. However, whether a particular mode is available on a particular board depends on the design of the board. QIO uses 4 lines for data transfer and DIO uses 2. The NodeMCU module I am using has a ESP12E on it. I guess, ESP12E design uses DIO instead of QIO to make two extra pins available for I/O. That's where having those extra pins broken out starts making more sense. The bottom line is - being consistent with SPI settings is not enough, you need to know which SPI modes your hardware can support.

2. The sample programs and AT firmware use an odd baudrate - 74880. Where as in my earlier experiments with ESP8266, all SDK code defaulted to the standard 115200 baud. I was not aware of this change. I tried all standard bauds in my serial console utility but it did not have the 74880 baud option.

Surprisingly (or not ;) ) these two facts are not documented anywhere.