File size larger than flash size

[kalpaknirale]

Hey everyone I have a qn freejoy.hex is 155kb and my stm32c8t6 is only 64kbs and 128kb how did yall get it flashed

Refer freejoy and freejoy configurator 

It gives me an error file size larger than flash size but other people seems to have workaround any guidence would help a lot

Thanks

[SofLit]

Hello,

Hex file does not reflect the real size of the application. It contains also the addresses: https://en.wikipedia.org/wiki/Intel_HEX

If your the generated binary exceeds the Flash size oh the MCU you beed to migrate to a bigger flash size device:

[kalpaknirale]

Yea but the freejoy file size is 155kb 

Even 128kb will not suffice 

[SofLit]

---

@kalpaknirale wrote:

Yea but the freejoy file size is 155kb 

Even 128kb will not suffice 

---

This is the size of the hex file need to convert it to bin format to know the real size of the application. If it exceeds 64kB there is no other solution than migrating to bigger flash size device of 128kB as I explained previously.

[Tesla DeLorean]

.HEX is an expansive ASCII representation of the binary data.

Around 2.5x larger than the data bytes that gets written into the FLASH memory

Convert it to a .BIN and see how big THAT is.

See HEX2BIN, SRECORD

[kalpaknirale]

Soo just to have a piece of mind, the 155kb should be 2.5 time lesser when it's in .bin format right ? Soo acoordingly 64kb should have been enough ? 

Is that how st link utility works ? 

[Karl Yamashita]

ST Link Utility has been NRND for a long time. It's been replaced with STM32Cube Programmer 

https://www.st.com/en/development-tools/stm32cubeprog.html

[Andrew Neil · Accepted solution]

---

@kalpaknirale wrote:

Is that how st link utility works ? 

---

It's a direct result of the Intel Hex format encoding - It has nothing to do with ST-Link Utility per se.

In the Intel Hex format, each byte of data is encoded as two characters - ie, 2 bytes.

So that immediately makes the data two times the size.

Then there's the added overhead of addresses and checksums - so the overall inflation becomes around 2.5 times.

See the link posted earlier by @SofLit 

#HexSize

[Tesla DeLorean]

>>Is that how st link utility works ? 

ST-LINK Utilities, and frankly most "PROM Programmers" for decades have been able to take Intel, Motorola and perhaps Tektronix format HEX files as a method of input.

Sort of format data you sent to the factory to get a Masked ROM manufactured, or you wanted your Distributor to "Add Value" by pre-programming parts before they shipped them to you, or your PCBA

STM32 Cube Programmer should also be able to take .ELF / .AXF files, and .DFU object files

I'm a pre-internet dinosaur, now you can find tools like SRECORD

https://srecord.sourceforge.net/

[Andrew Neil]

---

@Tesla DeLorean wrote:

STM32 Cube Programmer should also be able to take .ELF / .AXF files

---

Indeed.

@kalpaknirale  and those files will also be (significantly) bigger than the size of the actual code - because they also contain a whole lot of extra metadata:

https://community.st.com/t5/stm32cubeide-mcus/how-to-connect-w25q128jv-with-nucleo-l432kc-through-standard-spi/m-p/739235/highlight/true#M32094

---

@Tesla DeLorean wrote:

I'm a pre-internet dinosaur,

---

Likewise.

@kalpaknirale the origin of Intel Hex is back in the days when serial links couldn't be relied upon to transmit pure binary data - that's why it encodes the data into a purely text-only format.