Hello,
I'm creating an application which runs on Dallas 89C450 microcontroller. My application uses RTX-51 Full RTOS. The versions of the tools which are integrated into my IDE are like below:
C51 Ver: 7.50 A51 Ver: 7.10
My application used to work fine but I was having problems with my available code space. So, I decided to port my application to LX51 Advanced Linker V4.24 in order to use its code packing feature. But my application started malfunctioning after enabling code packing.
What might be going wrong? How can I solve this problem? Using code packing feature is quite important for me because it seems that it would solve my problems with available code space if it worked fine.
Please send me your opinions and advises. This is an emergency case.
Best regards...
Is it possible that I'm facing with a stack overflow problem. I couldn't find any option in IDE to detect a stack overflow failure.
I also installed latest release of uVision 3 (C51 ver 8.05 etc.) but unfortunately nothing has changed. What else would you offer?
I want to give you a more detailed information about my application. My target processor is a Dallas DS89C450 which has an on-chip 64KB program memory. It doesn't support using an external stack. Unfortunately, 256-byte data section of the microctontroller has to be used as a stack region. I'm using RTX51-Full V7.01 real-time executive for my multitasking purposes. My application is comprised of different operating system tasks devoted to special duties. Some portion of this RAM region is also used by this real-time operating system. Thus, I'm placing my local and global variables on an external RAM chip.
The available on-chip code memory is about to get full. So, I decided to change my linker to LX51 in favor of its better optimization levels and code packing option. But I started having problems with the operations of the system which has to be accomplished by the microcontroller that I mentioned.
The microcontroller is working on a device and cooperating with other two 8051-based microcontrollers located inside this device.Therefore, it doesn't seem to be able to use a full-blown ICE to trace the operation of the code in the run-time. But instead, I'm using a "printf" debugging strategy on a serial line. After enabling 9th optimization level and code packing, it seems that a line is not being executed in one of my tasks. But this line was executed before enabling LX51 and code packing. Moreover, all other lines and functions continue executing properly. After enabling 11th optimization level and code packing, abnormalities get even higher. Can this phenomenon happen due to a stack overflow? But I would expect the code to crash entirely because of a stack overflow. I would be appreciated if I could solve and learn the reason of this event that I had observed.
Thank you for your interest.
Best regards,
There is only so much code that you can cram into a 64K address space!
The higher Linker optimisations are clever, but they aren't magic - if your code is too big, then it just won't fit, I'm afraid.
I have seen the kind of symptoms you describe on a very full system - the answer was just to get rid of some excess code.
The trouble with printf debugging is that it just adds to the bloat by adding all those strings into the code space! :-(
Dont't you have JTAG access for debugging?
Can't you move some stuff onto the other processors?
After enabling 9th optimization level and code packing, it seems that a line is not being executed in one of my tasks.
That's probably a misinterpretation. The way opt 9 and higher work means that it becomes impossible to find out whether a given line of code is executed just from stepping through the C source code in a debugger. You have to look at the assembly code.
But I would expect the code to crash entirely because of a stack overflow.
That expectation means you have some serious misconceptions about how the 8051 architecture works. The 8051 stack mechanism doesn't have a solid wall it'll run into and crash.