The reason why the Base64 decoder is not working is because the buffer for storing the bit is a bit too short, I changed the buffer into a 32 bits variable so it can store all the 24 bits. After that I found that the if condition which will split the 24 bits into 3 8-bits bytes is not working, I then changed the condition from detecting the the 25th bit which indicates that 24 bits had been shifted into detecting the if the end of the of the 4 Base64 bits is reached or an equal character which also indicates the end of the Base64 data is encountered. The decoder now works but only able to decode 4 Base64 bits into 3 bytes per call of the decoding function.
The next task is to put the Base64 decoding function in the HTTP upload. There are few challenges in this and one of it is the need to buffer 4 bytes of data before the decoding function can be called. The even more challenging part would be that the latter parts of the 4 bytes would be in the next packet of data sent through the Ethernet, this would require the writing process and the buffering process to stop and return to fetch the next packet before continuing to do store the latter parts of the 4 bytes and decoding it and write it into the SD card. It is tough to find the nicest spot to insert this decoding function into the code, my idea now is to insert the decoding process just before the writing process and find a method to skip the writing process and go back to fetch more data when the packet data is finished and the 4 Base64 bytes buffer is not yet been filled.
Other than that, I also did some work on the CRC part of the SD card. To activate the CRC on the SD card, during the initialization process, CMD59 must be send with the leftmost bit as 1. The default code did not use any CRC checking so I would need to fill up all the CMD that I will be using with the correct CRC7. I calculated the CRC7 by using a simple program. It also should be noted that if a CMD19 is send, the first byte of the data is not 0b00010001, but instead is 0b01 “010001” which 010001 is the binary form of 19. The command byte is then followed by another 4 bytes, which could either be an argument or a sector address depends on the CMD it is sent with. The 5th byte would be the CRC7 byte which is determined by the previous 4 bytes. The CRC7 only has 7 bits. The 7-bits CRC7 must be shifted to the right by one bit and the least significant bit must always be 1.
After filling all the CMD used with their correct CRC7, it is time to send a 512 bytes data with the correct CRC16 following it. I first try to forcefully write blocks of 512-bytes 0xFF into SD card with the correct CRC16, The data is correct written into the SD card. I then try to change the CRC16 by giving it a wrong CRC16, the data is not written into the SD card and there is an error returned by the SD card stating a CRC error is detected. After, that I try to integrate the CRC with the upload system, instead of forcefully writing 0xFF from the code, I try to write the data from a file that is upload or the form data uploaded through the text area. I sent block of 512-bytes of character ‘A’, the CRC is calculated using this link. Both the file upload and text area upload is working but there is a minor bug I found in my code for the HTTP upload. There is a calculation error which if I would be able to upload through the text area, the file upload will give an extra carriage return character after the actual data which will mess up the CRC16 of the sector. If I modified the code to removed the extra carriage return from the file upload, the text area upload would not be working. I commit both codes, one with the file upload working only and one with the text area working only in my git.
0 Comments