-1

I have a little project with an STM32 where I send a file via UART and store it at a defined address in the flash memory. This works. Now I want to modify this and store a compressed file in the flash and uncompress it to a defined address somewhere else in the flash. I use 7zip to compress the file as .zip type with deflate method. As I understand correctly the data in the zip file are after the file name and the extra field. So I use a offset value in the local int bits(struct state *s, int need) function. After the start of the puff function I get last = 0 and type = 2 which looks ok. But in the while function in local int dynamic(struct state *s) I get a hard fault. So my questions are:

Is it ok for me to use a .zip file with deflate method?

Is it correct that the deflate data (including the 3 block bits) starts after the extra field?

Regards, Tobias

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
tobias witte
  • 11

1 Answers1

0

Yes, you can use zip to create the file, making sure you use the deflate compression method (the zip format permits other methods), and then puff to decompress the compressed data. However you then have to write some code to find the start of the compressed data, which is not necessarily just a simple offset. You need to decode the local header of the first entry of the zip file, which has variable-length fields. You can find the zip file format documented here.

Since you are compressing just one file, it would be simpler and the result smaller to use gzip instead of zip. The header is simpler, and easier to decode, but still has variable-length fields. Better still would be to use zlib to compress to a zlib stream, which has a fixed-length two-byte header, for the most compact and simple-to-process format. zlib is not a utility, but rather a compression and decompression library for which you would write your own code to do the compression.

In all cases you should check the integrity of the decompressed data using the check values in the respective format (zip, gzip, or zlib).

Also you have the option of using inflate from zlib instead of puff. Puff may be best for your embedded application, since it is small both in code size and memory required for decompression. However if speed is important, inflate is a fair bit faster than puff, at the expense of more code and more memory required.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Hello Mark, thank you for your answer and thank you for the puff files ;) The file name and data field size from the zip are in the header. I read them and calculate the offset were the data start. I were debugging the code today and see the problem happens in the dynamic() function. After the call err = construct(&lencode, lengths, nlen); err gets the value -7 so the puff-function do a break. I found out that the fast decode function do something wrong. After I inserted the SLOW define to use the slow decode function everything works. Do you have an idea why the error bevore happens? – tobias witte Jun 15 '18 at 10:52
  • Please provide a link to download the .zip file that causes the error without SLOW, and no error with SLOW. – Mark Adler Jun 15 '18 at 15:41
  • Sorry for the late reply. Here is a link to the file: https://www.file-upload.net/download-13214606/test.zip.html – tobias witte Jul 04 '18 at 06:49
  • I now noticed that still something goes wrong. The first 9 Bytes of my file gets unziped correctly. But byte ten has a symbol value of 257(dez) so in the function "codes" the program runs into else if (symbol > 256) , makes the value to 0 and sets outcnt+3. The real value of byte ten is 0x56. This happens on several bytes. In one case outcount gets incremented by 27 so there are several bytes missing in the out buffer. Do you have an idea why this happens? – tobias witte Jul 04 '18 at 07:00
  • I get no error from puff on the deflate data in that zip file, with or without `SLOW` defined. You must be doing something else incorrectly. – Mark Adler Jul 04 '18 at 16:37