I’m using CW 2.10 classic for PPC and would appreciate ideas on solving a problem I’m having. I’ve compiled a target for FLASH (the OS) who’s task is to communicate with a host PC over a serial port. There’s a second SRAM target (the app) that’s compiled and can get downloaded through the serial port and executed (i.e. the core stops running the OS and jumps to the start of the app). The SRAM app can call previously compiled functions residing in the FLASH target, plus interrupts can occur while the app is running and the ISRs are located within the FLASH.
Per PPC EABI, the startup assembler sets R2 and R13 to the _SDA_BASE and _SDA2_BASE for the FLASH OS but when the app runs, it does the same thus changes R2 and R13 to its own small data section. The problem now is that when the app calls the FLASH functions to access OS global variables or when an ISR routine accesses OS globals, R13 isn’t correct for the FLASH code. I’m looking for a solution to this, here’s what I’ve considered:
- Don’t initialize R2 and R13 in the app start-up. Problem is that the app globals in sdata2 can’t be accessed.
- Don’t use small data area in the FLASH OS. I can’t get this to work. Help menu suggests a pragma data_mode = far_abs but I can’t get the syntax to work. Additionally, help says that is the default anyway but I can see all the code uses R13 with indexed addressing.
- Comment out sdata and sdata2 in linker file. Compile complains.
- I’m considering re-writing the entire OS with all globals at a fixed memory location with pointers, but I’d like to avoid that.
- Also considering manually adding R2/R13 stack/load/restore to all the functions and ISRs but again would like to avoid.
Can anyone suggest a way to avoid this R13 corruption? I can make any defines, etc from the OS available to the app target if that helps with a solution. I think an elegant solution is one that prevents the OS from using small data and indexed addressing.
