In my fourth week, after Dr. Shawn saw my code of writing on flash memory which is playing with the pointer, he was like “why did you do that!?”. It was too complicated. Dr. Shawn said “Writing a complicated code is easy, the hardest part is how do you establish the same thing with simple coding”, which I totally agree with, a simple code is easier for maintenance and for other colleagues to understand. But that was the simplest solution I could come up with in order to make sure the firmware is intact instead of blind feeding it, giving it more than sufficient delay and hoping the internet is working fine that day. Then, Dr. Shawn suggests me the integrity checking could probably be done by simply checking Net_Pres_SocketReadIsReady() function which will return the size of the bitstream available on the socket. Yes, it definitely can! If the board have the size of the available bitstream, reading less than the required number of bytes can be prevented and the problem solved. I didn’t go with this route because I didn’t know that Net_Pres_SocketReadIsReady() will return the number of available bytes in the buffer, I thought it will return a true/false boolean as its name suggest, here come the importance of naming a function. In fact, at first I was given this task, I was thinking of using NET_PRES_SocketPeek() function to get the number of available bytes but it is definitely a very very bad idea because this function read the data, which is a total waste of processing power. Turns out the Harmony really does handle everything for you given that you are really familiar with it. And so I redo the flash writing with Net_Pres_SocketReadIsReady() checking and also write to the FPGA at the same time so that the transmission can stop when the buffer is cleared or the FPGA is done configured, and then return the client whether or not the bitstream is a valid firmware.
Afterward, I move on to working on implementing SSL over the TCP connection. SSL is basically the “https” you see on the url which provides a secure connection to the server and makes sure the server is who it claimed to be so that your sensitive information does not being sniffed by other users in the network or sent to imposer that is trying to steal your information. It is done by encrypting your message so that only the intended recipient can understand it and checking of the server’s certificate with Certification Authority (CA). With the example of wolfssl_tcp project provided by Harmony it is not difficult to implement the SSL. But after implementation of SSL the board reboot whenever it receives a HTTP request, and I get stuck here. Then Dr. Shawn comes to rescue, after his tweaking on the Harmony configuration we found that the culprit of rebooting is the stack size is not enough as SSL require more space for encryption. But then, the board server does not respond with the client’s handshake, this time, the heap size is not enough. Now the board successfully receive the request. But then, the board hang while trying to reply the client with longer content. This time, the TCP transfer buffer size is not enough. Now, all the requests work fine except the PUT request, the one that downloads the bitstream from client. I can receive the encrypted PUT request but could not download the file sent along. By capturing the packet with wireshark, I see that after the handshake is done, a 200kb packet of encrypted application data is sent via TLSv1.2, which is the PUT request line and request header, but then it sent a 1000kb unencrypted packet via TCP which fill up the board’s receiver buffer. The board stuck on waiting for bitstream and end the connection after timeout. Now the board only handle the encrypted socket, I think this is the reason it could not resolve the TCP packet. I am still working on this.
This is the last week of Nadia’s internship, I hope you know that it was really nice working with you and thank you for your encouragement. I wish you continued success in all your future endeavors. Take care and farewell. 🙂
0 Comments