The decoding problem of hardware JPEG decoding irrelevant code is finally solved.

Since July August this year, JPEG decoding was completed, but it has been very unstable. If you modify any part of the code, decoding may fail. At first I thought it was a stack problem, or there are invalid pointers later, but no results are returned. In the end, I can only doubt the compiler. In addition, After compiling with rvds4.0 in my same program, JPEG decoding always waits for timeout, but the header can be decoded, after obtaining the relevant JPEG information, the main part of the image cannot be decoded. I switched to rvds2.2 and the decoding was successful. In the same program, the different compiler results were different, which made me very disappointed with rvds4.0, however, I accidentally found that the JPEG cannot be decoded after the irrelevant code is modified in rvds2.2. I realized that I was wrong with rvds4.0. I began to find another solution. When I carefully read
After dataset, I finally found a glimmer of hope. The article said that the maximum clock speed of the JPEG Code cannot exceed 66 MHz. At that time, I modified the JPEG clock frequency division to 4, it happened to be 66 MHz. At this time, the decoding was successful. I was glad that it was not long before, but it was a tragedy. The printed information showed that the decoding failed and waited for the timeout, I started to suspect that it was the compiled address. I began to print the addresses of Various Buffers, pointers, and variables, and finally found a problem, if the last pointer of the source image address is 0 (hexadecimal), the decoding is successful. After many attempts, this conclusion is correct, finally, I found out the problem. The source image address must be 16-byte aligned, which can explain the incredible problems I encountered before.

I'm glad that this problem can be solved by adding a code. Because of the 32-bit CPU, the compiler is 32-bit alignment by default.

 

If (jpgaddr % 16) // the source address must be 16 bytes (128 bits) aligned. Otherwise, unexpected problems may occur, which has plagued me for more than five months. Jpgaddr = (jpgaddr/16 + 1) * 16;

In this way, after applying for the source image buffer, you can use a pointer pointing to the 128-bit alignment address closest to the starting position of the buffer to solve this problem.

 

Bare metal JPEG decoding: http://blog.csdn.net/cp1300/article/details/8007764