Following the functionality of the Base64 decoder and CRC checked writing process, it was time to move onto the next step to reach the objective set for the month. The next step is to integrate two specific portions into the current code; i) the Ping-Pong Upload mechanism and ii) Reading out the written data through the UART. Both of these tasks were handled with during the week although with different rates of success. Other than that, it was also time to study up on the Spartan 6 Configuration guide to prepare for the next stage of the project to be handled.
PING-PONG Upload Mechanism
For safety of data integrity purposes, the supervisor had previously proposed a “Ping-Pong” file upload mechanism where the reserved 1MB of raw sectors is split into two halves, and the data is stored in one half at a time. The first write is to occur in the first half and the second write operation is to occur in the first half. Once again, it should be stressed that if a write operation fails a CRC check, the data uploaded will not be written, so in this event, the pointer as to where to write the data (first half or second half) should not change. To implement this, the write functions were needed to be modified so that it can take in the sector address of where to write the data as an argument and start writing the data from there onward. This presented a new problem, which was then once the sector address is changed, the Write Multi-Block command is rejected by the SD card, as the CRC-7 [a dummy value when the CRC on the card is not activated] value changes due to the changes in the argument. Initially, the CRC table provided at the top of the stack was hard-coded with the correct CRC-7 value for the command, but soon it was evident that this was a poor solution as the sector address will change on the second upload (or entirely different sector addresses may be used in the future). So a new function called AesteSendMMCCmd was developed which sends the command to the SD card but with a CRC that the user inputs as an argument rather than the value in the table mentioned earlier. The main write function was also modified to incorporate this and so, for the write function, the sector address and the CRC-7 value for that address is used as arguments. It is hoped that in the future, a short CRC-7 calculator can be integrated into this part, so that the value doesn’t need to calculated and the only value specified in the Sector address. Hopefully, this can be done in the coming week or so.
Following this, the next step was to look at how to perform the switch. A simple flag to notify the PIC whether the sector is being written for the first time or the second was used to test out whether any bugs arise form this implementation. The flag was implemented in the PIC and found that after the correct conditions are specified, the “Ping-Pong” action is achieved and no error/bugs occur. The next step is to augment this idea to make the MBR of the SD card make the decision of where to write.
Reading out the written data through the UART
The FPGA will be configured with the user defined bitstream using the UART. So it is vital to confirm that the PIC can read out the correct data written into the SD card through the UART. To achieve this, a few functions were modified. The first was the AesteSectorRead function previously written by my colleague. Using only that function to try to read out the data to a buffer caused a lot of problems and bugs. So the function was modified to take in the address of the sector to read and the length of the data to be read (this would be the Filesize information obtained from the bitstream header file) [https://blog.aeste.my/archives/2892].
Another function which needed to be modified more was the MDD_SDSPI_AsyncRead function from Microchip. The actual reading action was replaced with a new set of instructions that takes in a byte from the SD card’s Raw Sector as defined earlier and transmits it through the UART. The same problem with the CRC-7 arises so the functions are modified to take in a CRC value as an argument and feed it into the command rather than using the CRC table as mentioned earlier. Testing out the code using Minicom proved that the sectors were being read for the length specified. The functions were further augmented into the “Ping Pong” upload mechanism to check for functionality bugs. No such bugs were found.
Studying the Xilinx Spartan 6 User Guide
To successfully program the Spartan 6 FPGA, certain signals need to be toggled at certain times prior to sending the bitstream to the FPGA. So, the Spartan 6 user guide was used to study up on this. Along with that, the workdone by former intern (https://blog.aeste.my/archives/author/kinwailee) was also studied via the blogs to better understand the design of the board, as well as the Master/Slave modes that are to be incorporated into the overall system.
CRC-7 Calculation
One important lesson learned in the week was how the CRC-7 for the SD card commands are calculated for the SD card to accept the right CRC-7 value. This was found to be a bit annoying as it is not as straight forward as the CRC-16 calculations. The SD commands are sent as 48-bit streams. the first 8 bits define the command index. However, the first two bits of that must be “01” and the command index must be a 6-bit BCD for the next 6 bits. So for Multi Block Write (command 25 for the SD card), the bits are arranged as “0101 1001” which makes the first byte of the command stream “59”. the rest of the bits are the argument for the command being sent. For most commands, its 0 but for the case of read/write, its the sector address. Once incorporated, and the value of the CRC-7 is calculated, one final step needs to be taken which is to shift all the bits to the left by 1 and add a 1 at the end. This is to ensure that the last bit in the command sent is always 1 (the termination bit).
Overall, it was a less eventful week compared to the previous one. A few step forwards were taken but no giant leaps. This was a bit due to the fact that through most of the week, I was feeling less than 100% , but I hope to make up for this in the coming week. I also learned an important lesson in communication during the week, which I hope I’ll learn from and improve myself in.
0 Comments