CP210x uart support

[alonewolfx2]

Can you add cp210x (usb-ttl) support? or how can i do this?

[alonewolfx2]

Or standart com port support like com1 com2

[mathijsvandenberg]

Hi Alonewolfx2,

Me or someone else will add standard serial port support soon,

Regards,

Mathijs

[alonewolfx2]

thank you.

[jmg5150]

Hi Alonewolfx2,

I'm also using silicon labs cp210x chips as the uart-serial bridge and I'm working on adapting the code to support using the generic virtual comm port rather than the FTDI specific implementation. As of right now I'm 95% done, just testing it out now, should have it posted in an hour or so.

[mathijsvandenberg]

Nice work Jonathan! I was already hoping you would be working on that!

[jmg5150]

As of 10 minutes ago I've got it "working". At the very end of the programming of the second file, the log shows the following failure:

Sending chunk [197/199] Sending chunk [198/199] Sending chunk [199/199] Flash part 2 (user) done Failure: got 2Bytes of data: 00 00 Finished

Even though it says failure here, the actual programming of the chip was successful and it has the new code I put on it using this program. Any insight on why the false failure here? Did it happen for you also, or is this a new bug based on my com port implementation? I'm trying to understand what's going on, hopefully have it sorted out soon.

[mathijsvandenberg]

The parts that looks like to fail is the FLASH_FINISHED command. This should reset the ESP8266. from esptool.py, it should return 0x00 0x00, But it does not. This is also the case with the esptool.py. perhaps this command need other input

i see that i made a booboo:

hex.AppendFormat(" {0:x2}", rxdata[x])

should be:

hex.AppendFormat(" {0:x2}", data[x])

However, it will still give an error message in the log.

Regards,

Mathijs

[alonewolfx2]

@jmg5150 if you share i can test it.

[jmg5150]

I've commited the code in my fork of the project and submitted the pull request to Mathijs. He'll probably merge it into the project sometime today. If you want a sneak peak, you can find it here: https://github.com/jmg5150/esploader -- any/all feedback would be very much appreciated. Note that as of this time, the code for the generic comm ports just does programming. I didn't hook it up to switch to the normal terminal after programming. Mathijs' original implementation was using a timer to check for arriving data however I'd like to do an event-driver implementation. I'll probably check in a working version of that in the next day or so.

[alonewolfx2]

@jmg5150 firstly thank you. its working and flashing but something went wrong with my cp210x. its not sync when i put my module in download mode and open port,select files than flash. its working with this steps. 1-open port 2-select files 3-click flash button and power up module(repeat this step for sync) in download mode. here is full log

COM Port OpenedOpening file C:\Users\Suskun\Desktop\share\firmware\0x00000.bin
Opening file C:\Users\Suskun\Desktop\share\firmware\0x40000.bin
Done Opening files
Connecting to target..
Invalid head of packet
Invalid head of packet
Invalid head of packet
Invalid head of packet
Invalid head of packet
Invalid head of packet
Invalid head of packet
Could not sync target..
Connecting to target..
Synced..
Flash erased
File is split up in 34 chunks of 1024 Length
Sending chunk [1/34]
Sending chunk [2/34]
Sending chunk [3/34]
.
.
.
Sending chunk [34/34]
Flash part 1 done
Flash erased
File is split up in 142 chunks of 1024 Length
Sending chunk [1/142]
Sending chunk [2/142]
Sending chunk [3/142]
Sending chunk [4/142]
Sending chunk [5/142]
.
.
.
Sending chunk [141/142]
Sending chunk [142/142]
Flash part 2 done
Finished

[mathijsvandenberg]

It looks like there is still something left in the buffer, However when the sync function is called, the 'esp_programmer.DiscardBuffers()' function is called which should empty them. I've merged the changed from jonathan to the master branch.

[jmg5150]

@alonewolfx2 Thanks for testing it out - as I worked with the tool last night a lot while flashing my own firmware down multiple times I've come across this issue as well. I'll spend some time today reviewing this section of the code and try to make it more reliable.

[alonewolfx2]

@mathijsvandenberg uploader says finished 2 binaries but binaries not working on chip. something went wrong on.

[jmg5150]

@alonewolfx2 I spent some time working on improvements to this tool to make it much more robust for the serial comm port version, as I noticied sometimes it would fail to write valid binary images as well. I went in and made sure all the functions would do their own error checking and return true/false to make sure everything was executing as expected. I noticed this improved reliability significantly. I also was able to improve the sync issue mentioned, however it's still not ideal (sometimes it requires a reset, other times it takes a few seconds, other times it works fine) - I'll need to spend more time tuning it. I also abstracted the the programmer out into it's own class object (so that if you're building your own C# application to test other features of your firmware on the device, you can just throw this in with it and then you can do everything all from the same program :)) Unfortunately this means that it's diverged very much so from this project that it's probably impossible to do a merge. Since it's largely based on Mathijs's code (just significantly refactored) I'm going to see if he wants to try to do a merge on it, otherwise I'll put it up as a separate project.

[mathijsvandenberg]

@jmg5150 Thanks for digging into the code. I was planning the same class as you just implemented. This weekend was full of social things, but this evening i will be able to lookover the code, and will merge it into the master branch!

Thanks!