This week I continue trying to figure out how to ‘download’ a huge file with TCP protocol. Set up a USB cdc com port to ease debugging. Fixing ‘init_b’ staying LOW.

TCP Server looping READ socket

To be able to ‘download’ or I should say read a file being uploaded by a CLIENT is to loop the socket READ state. Continuously looping the READ & WRITE socket, both CLIENT and TCP Server (PIC32) will automatically communicate packet by packet of data. Therefore just by extracting the read buffer the particular data send by CLIENT will be stored.

Curl as CLIENT

Curl provides multiple solution in uploading a particular file to a SERVER site. I first experiment with

$curl -X PUT -F [email protected]' http://IPaddress

However, the problem with this is error like ‘Expect 100-Continue’ and ‘—–boundary=some_random_number–‘, after some minor tweak, eg: SERVER side responding with ‘Content type: multipart/form-data, octet-stream application’ I could actually able to transfer ‘mytext.txt’ to PIC32. Then again another issue arise, which is the existence of the boundary. This boundary is really annoying to filter if a very simple TCP server socket was set up.

Setting up USB cdc com port

To ease my debugging, I set up a USB cdc com port that will output all the error messages and other information onto a serial port. Setting this up is fairly simple, by default all the TCPIP example from Harmony already have this set up, just need to look up the baud rate being set, then assuming minicom was used. Surprisingly my board’s USB is working, woots~

$minicom -s
- set baud rate
- usb/ttyACM0
- hardware flow 0
- save

Wireshark, curl and usb

Next, I change my curl command to

$curl -X PUT --data-binary "@somebinary.bit" http://IPaddress

For the file I am transferring to PIC32 is a binary file format. Analyzing the packets that was send with Wireshark, curl’s ‘–data-binary’ command did not manipulate the binary file data and only uploaded to SERVER side as binary data. With the above command I could also avoid filtering the boundary string and some extra header information. Since all these data is in binary format, thus must be converted to string to output on a serial port.

uint8_t buffer;
uint8_t *someBuffer;
forloop{
sprintf(&someBuffer[i
2], %02X, buffer[i])}

Keeping in mind, ‘buffer’ array stores the binary data, and from my experiment if ‘char’ was used as declaration for ‘buffer’ array, the string conversion will be wrong!

Based on the output from serial port and double confirm with wireshark, I am pretty sure the data was transferred correctly!

F**king ‘init_b’

After much experiment and using a CLEAN project, I found the bug was on the initialization of TCPIP stack. When the project runs without TCPIP stack initialization, ‘init_b’ will be happy and gives a HIGH output. I do not understand this weird behaviour, because I have check every single tcpip stack stuff but could not identify which configuration could have affect ‘init_b’. This bug is really weird, I have check forum but nobody reported this issue. And the funny thing is that I could still configure FPGA even with ‘init_b’ low but its only a one time thing, to re-configure a power off is necessary.