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.
Here's another good one. Again, works fine on simulator/debugger, but not on the target hardware. If I do this: BYTE process_Help(char *cmdBuffer) reentrant { cmdBuffer[0] = '\0'; printf( "Help Message"); return TRUE; } everything works fine. But if I do this: BYTE process_Help(char *cmdBuffer) reentrant { char *strHelp = "Help Message"; cmdBuffer[0] = '\0'; printf(strHelp); return TRUE; } it works fine on the simulator/debugger, but nothing is displayed when executed on the target hardware. Any/All help welcome and appreciated. Thanks, Chris Beattie
That's probably because the linker is detecting a call to the function in both interrupt and non-interrupt functions. That makes it necessary to declare the called function reentrant so a simulated stack can be configured in the the appropriate memory. You'll need to configure your startup.a51 file for this and add it to your project if you already haven't.
I can not duplicate the error. Can you post code that will generate the error.
If this is true, then you are in a real mess because printf is non reentrant. Also if this is true, you should be getting L15 : multiple call to segment errors, which you did not mentioned.
Not getting any L15 errors, just the L13's...
I don't think this is the case, but if it were, what do I need to set up in the startup.a51 to allow for it? I've already included it and customized it to some extent. Thanks, Chris
I'd be happy to zip up and send you the entire project (I actually just renewed my annual maintenance agreement). If you can send your email address to CBeattie@yahoo.com, I'll respond from my real email address. Thanks, Chris Beattie
You can download the code from: http://briefcase.yahoo.com/bc/cbeattie/lst?.dir=/Keil&.view=l
Your code uses funtion pointers. They are tricky to use in the Keil c51 compiler. If you can, delare them in the function that uses them. Otherwise you have to do some tricky stuff with the linker. I suggest to change HandleNormalData to:
BYTE process_EraseFlash(char xdata *cmdBuf); BYTE process_ProgramFlash(char xdata *cmdBuf); BYTE process_GO(char xdata *cmdBuf); BYTE process_DisplayMemory(char xdata *cmdBuf); BYTE process_Help(char xdata *cmdBuf); void uart0_HandleNormalData(void) { static const CmdData code gCmdTable[] = { { "EF", process_EraseFlash }, { "PF", process_ProgramFlash }, { "GO", process_GO }, { "DM", process_DisplayMemory }, { "HELP", process_Help }, { "?", process_Help } }; static const BYTE code gNumCmds = sizeof(gCmdTable) / sizeof(CmdData); //..the rest of the code <\pre>
Jon, Could you please explain what this "tricky stuff" is? What is the difference using funct ptrs declared in and out of the function?
Could you please explain what this "tricky stuff" is? http://www.keil.com/support/docs/210.htm Application Note 129 And see OVERLAY in the Linker manual.
I'm not sure what "tricky stuff" you're referring to but I tried replacing the fcn pointers with a case statement and had the same results, so I don't think it's that... Anyone have any ideas on the wierd L13 Warnings? I'll post the code again... http://briefcase.yahoo.com/bc/cbeattie/lst?.dir=/Keil&.view=l Chris
Here's the link for application note 129: http://www.keil.com/appnotes/docs/apnt_129.asp
The Dallas 520 chip has the XDATA memory internal to the micro. There is 1K of static ram interfaced internally starting at XDATA address 0. There are no speed issues invloved either with this ram - it works at the full execution speed of the device. The optional wait states only affect memory/peripherals accesed extrenal to the chip.
Are you sure, you've properly set up the memory of the emutator (Must be of same size as the memory in your target hardware)? Maybe your code is using more memory than exists on your target hardware (applies only to xdata and code). So the additional xdata memory would be provided by the emulator, but doesn't exist in your target's hardware.
Are you sure, you've properly set up the memory of the emutator (Must be of same size as the memory in your target hardware). Maybe your code is using more memory than exists on your target hardware (applies only to xdata and code). So the additional xdata memory would be provided by the emulator, but doesn't exist in your target's hardware.