 |
 |
| View previous topic :: View next topic |
| Author |
Message |
benoitstjean
Joined: 30 Oct 2007 Posts: 605 Location: Ottawa, Ontario, Canada
|
| 5.026 vs 5.116 using same code |
Posted: Thu Feb 19, 2026 8:33 am |
|
|
Device: PIC24EP512GP806
Compiler: 5.026 and 5.116
Just thought I'd run this by here and it's not critical to get it resolved because my stuff is working.
I just sent this to CCS but I doubt anything will get done about it, especially because I am not allowed to share my customer's code.
Anyhow, now that the bootloader problems are behind me, as I was trying to figure-out if these bootloader problems were caused by my older PCD version 5.026, I decided to try with the 5.116 version I purchased 2 years ago.... It turns-out that 5.116 cause more problems than anything else. I have done some testing to compare both PCD versions and here are the results.
TEST 1 -- COMPILING FULL CODE:
Compile firmware under 5.026 and include 5.026's bootloader.h file: compiler comes back with 59% RAM and 92% ROM.
Compile firmware on 5.116, returns Out Of ROM. Tried commenting-out the pcd_bootloader.h but same problem.
TEST 2 -- COMPILING with REDUCED CODE:
In order to compile successfully under 5.116, I have to change an array size from 80 elements down to 5 elements in my firmware. This does not help as I need it but it's for testing purposes.
Compile firmware under 5.026 and include 5.026's bootloader.h file: compiler comes back with 40% RAM and 91% ROM.
Compiler firmware under 5.116 and include 5.116's pcd_bootloader.h file: compiler comes back with 58% RAM and 94% ROM. This is quite significant. But that's not all...
CODE UPLOAD AND FUNCTIONALITY:
Using 5.026's bootloader.h to upload my firmware (also compiled under 5.026) to my device over Tera Term using that bootloader: all works as expected as it always has.
Using 5.116's pcd_bootloader.h to upload firmware (also compiled under 5.116) to my device over Tera Term using that bootloader: when device finishes initializing the modem, all of a sudden the code just jumps somewhere random in memory and the device does not work and that jump to that location prints stuff in my terminal and it is just stuck in an infinite loop displaying the same thing.
I say random because if I reboot my device, it is always jumps at the same spot during boot time and is stuck in the same loop.
However, although I haven't tried, I'm sure that if I change my code to add or remove functionality and recompile, it would probably jump at different times during runtime and at different location depending on what it causing the jump in the first place.
Then lastly, if I recompile my firmware still under 5.116 but this time without the bootloader and upload the code using the ICD-U64, the device appears to work as expected (mind you that I still have to keep that array reduced from 80 down to 5 explained in TEST 2 above).
Not sure what you think of this. Of course I'm not allowed to share the customer code but these are my observations and it is repeatable and the results are consistent.
I'm posting this here just to see if anyone has any explanation for this. Colleagues and friends tease me when I stick to older firmwares and sofwares but it doesn't mean that because it is newer that it is better (hello Apple!).
Cheers,
Ben |
|
 |
gaugeguy
Joined: 05 Apr 2011 Posts: 355
|
|
Posted: Thu Feb 19, 2026 9:33 am |
|
|
Changing compiler version on an existing project requires extensive testing to ensure everything still works as it previously did. The amount of retesting required usually makes it wiser to stay with the same version unless a newer version is required to gain a bug fix or new functions.
Newer versions may change initializations, optimizations, and functions may be altered to add bug fixes or new features. These things can cause the size to increase but can also cause some things to not work the same.
If the processor used is being changed to a newer, cheaper one then that is usually a good opportunity to use a newer version as the level of testing required is already there. |
|
 |
temtronic
Joined: 01 Jul 2010 Posts: 9623 Location: Greensville,Ontario
|
|
Posted: Thu Feb 19, 2026 10:25 am |
|
|
FWIW...
Since I'm a dinosaur, I like the 'if it ain't broke, don't UPDATE' policy.
Have heard far too many horror stories of 'it doesn't work anymore' after the update.
Stick with what WORKS, unless you absolutely need to. |
|
 |
Ttelmah
Joined: 11 Mar 2010 Posts: 20035
|
|
Posted: Fri Feb 20, 2026 3:22 am |
|
|
Yes.
I have outlined before my approach on this.
Use new releases, when they fix a problem, or add a feature you want.
When I compile code, I add a note in the header saying what compiler
I am using. This is a running note, so if a new release is used, and then
a problem appears, I can look and see what I used before.
I keep copies of every compiler that is known to work with a particular
piece of code.
Sometimes new releases actually work fine, but require changes to syntax
on something. If so, note this. |
|
 |
|
|
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
|