We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hey, I am trying to do a simple assignment where I am assigning one long to another. The left side of the equal sign is an element in a structure that is part of a union including other structures and a buffer array. It is referenced using a pointer to the union. The right side of the equal sign has an element of a structure that is also part of a union including a buffer array. command_data->status_struct.baseline = data_logger_status_0.status_data.baseline; It compiles fine, but when I run it, it cause the program to crash in a totally unrelated area of the code. In fact the function in which this snippet resides is not even called anywhere in the code for now. Does the C51 compiler have problems with longs?
"it cause the program to crash in a totally unrelated area of the code." So how do you know for sure that this is what's causing the crash? How do you know that it's specifically the fact that it's a 'long' that causes the problem?
I use longs all the time and have had no trouble. (I wish I had 64-bit "long long" support, but that's not a bug.) The code snippet makes an assignment to a value referenced by a pointer. Are you sure that the pointer point to the right place? Writing through uninitialized or bad pointers and thus trampling other data or program store is a classic kind of bug. You say that this routine isn't even run. In that case, why would the type of data make any difference, much less the operations on it?
"Writing through uninitialized or bad pointers and thus trampling other data or program store is a classic kind of bug." Especially in Keil C51, where an uninitialised/corrupt Generic Pointer could easily be pointing into the Stack...!
where an uninitialised/corrupt Generic Pointer could easily be pointing into the Stack...! Even worse, a NULL generic pointer points to 0x00 in DATA space which is register bank 0. Jon
I seem to have found the problem. It appears that when I add the long routines that a code segment called LIB_CODE, which is created by the compiler itself, gets bloated beyond a 255 byte limit. Any function beyond this limit will not work properly. I found this in another large function that I had which is now fixed. Is there something in the compiler configuration that will allow code segments larger than 255 bytes?
The LIB_CODE segment contains compiler helper routines from the library. As far as I know, it is not limited to 255 bytes. Jon
Are you using any sort of linker controls or other means to absolutely locate other parts of the code at address 256? Does a boot loader or something similar assume that application code starts there? Any possible hardware issues decoding the top byte of program store fetches? What's special about address 256 with your part and board?
Well, who might have guessed. I turns out that it was a linker problem. All along I was using the memory layout from the Target Dialog window. This was putting code into my iterrupt vector space. After looking over some code on the Cypress web site I discovered that they do not like to use this window. They use the BL51 Locate window to keep this from happening. This would not be a big deal if Keil didn't tell me that putting code into vector space was OK. Peace, Joe
I put code in vector space. Of course, I avoid the addresses that I need for interrupt vectors for hardware that I actually use. But the rest of the code memory in the first page is fair game for other purposes. Does Cypress devices have some special restriction in this regard? It would be a good thing to remember if I ever have to use one in the future.