The optimization of the firmware continued with the focus being on the SD card reading stack. A look into the USART’s synchronous mode functionality was also taken to try and understand how that works. There was also a lot of time spent trying to set up scenarios to break the upload mechanism and see how the system behaves under non-standard conditions.
USART synchronous mode
The term USART stands for “Universal Synchronous Asynchronous Receiver Transmitter”. So far, only the “Asynchronous” functions have been used to communicate with the PC for this particular component. However, the synchronous mode provides faster data transmission which is key to the project.
In synchronous mode, a separate clock signal is transmitted with the data. This clock signal is generated by the master, and both the master and slave sample and transmit the data according to this clock signal. In Synchronous Master mode, the data is transmitted in a half-duplex manner, i.e. transmission and reception do not occur at the same time. When transmitting data, the reception is inhibited and vice versa. The synchronous mode can be easily set-up in the OpenUSART() function form the usart.h library. This function is usually used to configure the USART’s functionality in the program. The tricky part is using this in conjunction with a correct SPBRG value in the configuration. For asynchronous mode, the value for the SPBRG can be easily looked up in a table provided in the datasheet for the dedicated PIC micro-controller family (Pages 307 & 308 in http://ww1.microchip.com/downloads/en/DeviceDoc/39762a.pdf). For synchronous mode however, it is important to understand how the values for SPBRG is calculated.
The baud rate for synchronous mode is calculated using the formula [Fosc/4(spbrg+1)] where Fosc is the micro-controller’s clock speed. Thus theoretically, it is possible to use a synchronous baud rate which is 1/4th of the micro-controller clock speed of 25MHz by setting the SPBRG to 0. This gives a baud rate of 6.25Mbits/sec. This means that the USART can possibly be used like an SPI peripheral. Using this information, it could be said that it is possible to transmit the bitstream from the SD card synchronously through the USART of the PIC within 0.5 seconds.
A few bugs were encountered when trying to test this and it was found that the programs loops infinitely if the SPBRG to 0. The cause of this is yet unknown but it is hoped that a solution can be derived in the coming week or so. However, it was possible to test out the functionality with a SPBRG value of 1, and it was found that the complete read process was completed in about roughly 4 seconds. This is still slow compared to what is expected according to the theoretical explanations. More digging is to be done about this.
Tweaking the SD card reading stack to perform better
As explained in the week before, the current read process subtracted 1 byte at a time to update the counter which counts the number of bytes to be read to fully read the bitstream. This made the overall process very inefficient. So, the solution devised was a sector counter to count every 512 bytes read rather then every byte read. This calculation for the number of sectors to be read is done right before the read process starts and the FileSize obtained from the bitstream is used to calculate this value. The sector count counts the number of sectors to be read excluding the very last sector. To allow to successfully read the bytes from the last sector to be read, an if condition for SectorCount=0 allows for notification to the stack that the last sector is being read. As for how much of the last sector to read, this is determined by the following formula [Filesize – SectroCount*512]. Using this last piece of information, it was possible to instruct the USART to only transmit the data until that point of the block. It should be noted that the PIC will still read the whole of the 512 bytes in the last sector, but only transmit the data that is part of the bitstream.
Once again, only the reading process was timed and these modifications made a small difference only noticeable when one of the PIC’s timers are used. Using a stopwatch, the time still appears to be around 0.7 seconds.
Upload interruptions and consequences
One of the non-standard scenarios to be tested out is the eventuality that the upload is interrupted (either due to power cut, network/browser problems etc) and its consequences. This scenario was easy enough to simulate by simply stopping the browser first and then closing it completely before the upload is completed. It was previously expected that perhaps the PIC will display a CRC error in this event, as the data received partially will not agree to the expected CRC value. However, what was observed was completely different. The PIC indicates no CRC error. The PIC instead remains in idle state, ready to accept a file upload. With a bit of digging the reason for this behaviour was quite evident. While writing data to the raw sectors on the SD card, if a block is partially written when the data stream is disconnected, the data partially written into the block is dumped. The SD card should however retain some of the previous blocks written as the data has already been accepted by the SD card. This may occur even if a valid Data_Stop_Token is not sent.
Inspection of the data in the raw sectors of the SD card confirm this suspicion, as some (often very little compared to the amount of data actually sent to the SD card through the upload protocol) remained. But the overall functionality is protected by the Ping-Pong upload mechanism as it performs for exactly the function intended, protect the FPGA from incomplete/incorrect bitstream data.
For an interrupted upload, the MBR is not updated, and thus according to the MBR the correct bitstream version is still the previous one. So if the FPGA is programmed, it will be done with the complete version that is stored on the SD card. However, another fail-safe may be necessary for the first-time upload failure scenario (i.e. the upload is interrupted for the first version of the bitstream itself).
Other than the work done on the parts stated above, more optimization was done on the Flash memory occupied by the firmware on the PIC. More unnecessary/unused functions were removed and the Flash memory now reads 54% used. It is now very difficult to find unused code stacks in the firmware now but it is hoped more will pop up and the target of bringing the flash memory used to 50% can be achieved.
0 Comments