 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019 Posts: 679 Location: Des Moines, Iowa, USA
|
| Error 71: Out of ROM, A segment or the program is too large |
Posted: Wed Jul 01, 2026 11:54 am |
|
|
Revisiting this topic which has come up in this forum from time to time.
We have one PIC24 project that is too large when we enable our debugging/printf support. As a simple workaround, I use an #ifdef to omit the message handling code. This is how we've used it for years.
I now find myself in need of debugging the message handling code.
Per repeated advice in this forum, all our C files are #included, so I can easily change the order. This is a game of Whak-A-Mole(tm) without more understanding of how things fit into these segments.
I have also split up the large function where the error appears. Then it just moves to the second. Then the third.
After commenting out most of the debug prints, I get to a "almost" fit:
| Code: | Seg 0AA00-0ABFA, 0006 left, need 000B0
Seg 00000-00002, 0000 left, need 000B0 Reserved
Seg 00004-001FE, 0000 left, need 000B0 Reserved
Seg 00200-055FE, 0006 left, need 000B0
Seg 05600-0A9FE, 5400 left, need 000B0 Reserved
|
You will see we actually have plenty of Reserved space, but our LEGACY design splits the flash into two segments for firmware updates. Or future design uses a bootloader and does not have this issue. We have plenty of space in the future version, but that does not help me with this one.
What can I look at to figure out what I can move and where? Do all files in the same C file get glued together in the order they appear in the file.
Is there any padding that would allow me to get there by moving things around? Or am I truly B0 bytes too large, period?
Thanks, much. I have read through sevearal old posts here about this topic, and now I want to dive deeper. _________________ Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202, 24FJ64GA002 and 24FJ1024GA606. |
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 20100
|
|
Posted: Wed Jul 01, 2026 12:15 pm |
|
|
Try using #separate on some of the subroutines. Also you could
try the compress option for #opt.
The latter though can make code much harder to debug.
The compiler tends to default to inlining small functions. |
|
 |
jeremiah
Joined: 20 Jul 2010 Posts: 1421
|
|
Posted: Wed Jul 01, 2026 1:25 pm |
|
|
| You can also see if your code already has any #org directives. They could be artificially limiting certain blocks of memory in size. If so maybe you could adjust those some. |
|
 |
newguy
Joined: 24 Jun 2004 Posts: 1943
|
|
Posted: Wed Jul 01, 2026 4:57 pm |
|
|
printf is very likely being inlined for every instance; I speak from experience and have stared down the same issue in the past.
As Ttelmah has said, the compiler defaults to inline-ing printf statements. You can force it to reuse code by wrapping printf statements in your own my_printf(args) { printf(args) } functions. That will save a lot of ROM, but tedious. |
|
 |
Jerson
Joined: 31 Jul 2009 Posts: 134 Location: Bombay, India
|
|
Posted: Wed Jul 01, 2026 7:44 pm |
|
|
| Adding to what ttelmah has written, you can split some long subroutines into sub-subroutines. That allows the compiler to place them in available segments rather than one long contiguous one. You may find solace in #separate and splitting code into smaller functions. |
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 20100
|
|
Posted: Thu Jul 02, 2026 12:37 am |
|
|
Newguy is spot on about encapsulating printf's. That is one that can use
a _lot_ of space. Even if you can only wrapper a few of these, you may
well be surprised at what this can save. |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|