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.
Hi All. A subtle but interesting problem cropped up from a Salvo user ... basically, a service wasn't working because the user had placed Salvo's global variables in xdata space AND Cx51 happened to put something that can be pointed to at X:0000. The run-time error-checking code inside Salvo thought that the parameter passed was a NULL pointer, and rejected the operation. So I have two questions: 1) Does Cx51 always re-organize the order of global variables in a file, when placing them in a data section? Salvo's mem.c specifically has, as its first global variable, one that is never pointed to, so it's OK if it's at a 0x0000 address. But Cx51 jumbled the variables (a bunch of arrays, mainly) around, and one of them ended up at X:0000, which caused the problem. 2) What's the easiest way to ensure that nothing is placed at X:0000? I.e. to start the "valid" xdata space at X:0001 or whatever ... Thanks,
"Does Cx51 always re-organize the order of global variables in a file, when placing them in a data section?" It seems to have a mind of it's own on this score. You can check the "Keep variables in order" box in the C51 tab, but be warned that it ignores this for uninitialised code space variables. I don't know how it behaves with uninitialised XDATA variables. "What's the easiest way to ensure that nothing is placed at X:0000? I.e. to start the "valid" xdata space at X:0001 or whatever ..." You can specify the XDATA size and range in the "Target" tab in the project options.
You could add the following assembly code:
xseg at 0 XNULL: DS 0x10
Stefan, Jon: Thanks. I'll add these solutions to our documentation. Regards,