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?
"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.