You have about 1 Mbyte of data to store. EEPROM is cheap in the scheme of things. The expensive part is waiting 20 minutes to capture the data. The obvious answer there is to increase the baud rate.
At 115.2 kBaud the transfer would take 12 times less, or about 2 minutes after accounting for some protocol overhead. So go fix the firmware to use a reasonable baud rate.
Complete is never possible. You can just raise the effort & cost.
It has nothing to do with 'cortex m4', but everything with the manufacturer's implementation of the chip.
Your chip has the usual set of read/execute protection bits. I doubt much is known in the (open) literature about the detailed weaknesses of such a new chip.
Very generally speaking, such a 'run-of-the-mill' protection scheme is OK against individual hackers, most countries, and low-budget competitors. It probably won't hold against a large corporate competitor (IBM/Apple/Google sized, especially if they own a chip fab), the CIA, or the combined effort of the hacker community.
A notable way to protect your code is to hide as little as possible, so reduce the population that will take part in hacking your product. If the 'combined hacker community' wants to do something with your device that you don't really object to, make sure they can do that without totally hacking your device. That will substantially reduce the combined effort put into hacking it.
What the mechanisms will be that can be used to circumvent the protection scheme of this particular chip can't be predicted, but you can read how other chips have been cracked for an idea of the range of methods. Just a few:
- out-of spec power supply voltages and/or cycling
- careful monitoring of supply current
- decapping the chip and disabling the protection scheme by UV light, or by cutting lines
- decapping and reading the electrical charges (or currents) in the memory array
Best Answer
Since the M4 core (and pretty much any other CPU used in a microncontroller) is turing complete, the answer to your first question is yes, conditional on the other details of the MCU.
In particular, while the CPU itself is certainly capable of the instructions required to do JPEG compression, it must have enough RAM to implement whatever algorithm is chosen, so your question should include additional details of the specific MCU. A very quick Google search indicates that entry-level M4 MCUs include something like 64 KiB of RAM, which is almost certainly sufficient to perform at least a basic JPEG compression, since, wiht the right options, JPEG is generally a multi-pass streaming compressor (i.e., works its way though the data without needed random access). Exceptions include the DCT step, but that's only an 8x8 (perhaps up to 16x16 depending on chroma reduction settings) block, so only requires a small amount of RAM.
For more details, you need to dig into the JPEG standard, and decide what subset you want to support. Since you own the encoder, you can just generate JPEGs using the settings that work with your limitations. This is much different to writing a decoder for general JPEGs, since then you must support whatever options and modes the encoder chooses.
A good primer on memory use can be found in the mozjpeg readme - it is brief, but at least includes key info, including the fact that progressive mode is generally out for your use case since it requires a whole-image buffer.
About your second question, it is unlikely that you'll find an existing library targeting the Cortex-M specifically that accepts RAW. You may have to combine a library that supports RAW decoding with one that supports JPEG encoding, and ensure that the interface between them allows streaming. Something like mozjpeg may be a good start on the JPEG side. You may need to adjust how temporary results are stored depending on your exact configuration.
If you can't find a JPEG library already targeting this MCU, you may have to compile one of the existing free ones yourself. This one looks promising since it explicitly targets MCUs and low memory use, but the linked author's page is 404, which is less promising.