I've recently begun work on maintaining and adding functionality to an existing product using the Chipcon CC1010. <snip>
I'm not sure what's going on with the forum here but this is the remainder of the message The jist of the problem is that when I turn on optimization the device resets after transmitting on the UART. We're now at our code space limit and can't add additional functionality without using optimization. I've written interrupt driven code that uses one UART while the existing code uses the other. My UART driver works fine. The existing code base blocks while the transmission is taking place (Yuck!) - waiting for the TX flag to be set before loading the next byte. It actually goes through a series of steps sending first a prefix, header, body, then postfix... each one blocking along the way and called immediately after one another. This goes against my general practices so I took this all out and transmitted the entire message from the TX interrupt. The whole message is transmitted and THEN it resets. The old method would get so far as to transmit the Prefix before resetting. Am I possibly heading down the wrong path with this? I imagine that it is very possible that the reset has nothing to do with the actual serial transmission but that certain conditions are being met after/during the transmission. If I don't trigger the serial transmission on this UART, the device will happily sit there talking away on its other UART (tx int driven). When I replace the existing code with the tx int version it still resets but only after the entire transmission. The code that follows after this looks fairly harmless. If the following code were the issue I would expect the blocking method to also be able to transmit the complete message. Using the old implementation, and without optimization turned on I can step through the code fine. When opimization is turned on and i try to step into one of the function pointers that handles the serial tx, the IDE displays "multi single step" (down in the bottom left of the IDE - where "ready" usually sits) and increments up past 1600 before reseting and returning to main(). The new interrupt driven method removed all of these function pointers but still suffered the problem, just at a different stage. I would greatly appreciate any help, pointers, or advice that anyone might please be able to offer on this. Unfortunately, until I arrived here, all development was done with optimization turned off. There is a vast amount of code that needs to be rewritten but I don't want to head down that path just yet only to find out that it doesn't resolve the problem. I would really like to know what is causing this. Kind Regards Darcy uVision 2.40a C51 v7.50 AX51 v2.14 LX51 v3.65b Level 0-1: All data transmitted Level 2-3: allows some of the data to be transmitted before the reset Level 4-9: allows a very small amount of data to be transmitted... where: 2: Data Overlaying 3: Peephole Optimization 4: Register Variables
"Using the old implementation, and without optimization turned on I can step through the code fine. When opimization is turned on and i try to step into one of the function pointers that handles the serial tx..." (my emphasis) Are you really using function pointers? If you are, have you carefully read all the application notes and knowledgebase articles about function pointers in C51? The nature of the 8051 architecture imposes some particular restrictions on the use of function pointers - especially when you enable the Data Overlaying optimisations...
I'm using numerous function pointers elsewhere for time management and these work fine with optimisation - but their use is quite controlled. I'd removed all the function pointers from around the suspect code but it's possible they're being used elsewhere (in the same file). Doesn't the compiler normally complain about reentrant functions in these scenarios? An example of poor compiler understanding was that the previous code was calling functions like memset and memcpy from within interrupts!! :) Thanks for the tip on that one. I'll keep looking for further use of the function pointers. I have found that I can individually optimise files in the project so I've set everything to 9 except the screwy file. It freed up 10k so this will keep us going until we have time to sort it out. Any further suggestions would be appreciated though. :) Cheers Darcy
"Doesn't the compiler normally complain about reentrant functions in these scenarios?" Not necessarily. The problem is that the compiler (and Linker)can't necessarily tell at build time that you have potentially reentrant calls via pointers. That's why you have to understand the issues first, and write the code accordingly.