We are using CW 5.0 for S12X on a S12XEQ384
We have verified the bus clock really is the 40MHx we expect it to be. We have just discovere that the RAM zeroing code is taking almost 80ms to complete.
We have been investigating where our start up delays are coming from.
We are monitoring an unsed micro pin with a scope. The pin is pulled up to 5V via a 20k resister. We placed instructions to configure the pin as an output and pull it low at progressively earlier points in the initialization.
When we got to the begining of main() and still had a lot of delay, we started looking in start12.c
After measuring the time at CopyDown, then at ZeroOut, there was a difference of 79.6 ms.
This is the start up data generated by the linker:
STARTUP SECTION---------------------------------------------------------------------------------------------Entry point: 0x7F4168'G (_stext)_startupData is allocated at 0x7F41C6 and uses 7 Bytesextern struct _tagStartup { unsigned nofZeroOut 3 _Range pZeroOut 0xFD800'G 2047 0xFE000'G 3976 0xFF000'G 2054 _Copy *toCopyDownBeg 0x7F53B9'G} _startupData;
This is the the zeroing code from start12.c:
ZeroOut: LDX _startupData.pZeroOut ; *pZeroOut LDY _startupData.nofZeroOuts ; nofZeroOuts BEQ CopyDown ; if nothing to zero outNextZeroOut: PSHY ; save nofZeroOuts LDAB 1,X+ ; load page of destination address LDY 2,X+ ; load offset of destination address STAB __GPAGE_ADR__ PSHX LDX 0,X ; byte count CLRANextWord: GSTAA 1,Y+ ; clear memory byte DBNE X, NextWord ; dec byte count PULX LEAX 2,X PULY ; restore nofZeroOuts DEY ; dec nofZeroOuts BNE NextZeroOut
This seems too long for less than 12k of RAM.
But 40MHz bus you have after initializing PLL, which happens probably after ZeroOut? What is your oscillator clock? 4MHz?
Hello,
Perhaps the solution is not to use automatic ANSI initialisation of variables, but to write your own function for explicit memory initialisation, to be called after the bus is running at operating speed.
Another possibility is to manipulate the PRM file, or vector table, so that special "pre-startup" code is run from the reset vector, which could set the required bus frequency. This code would then jump to the "traditional" startup code.
Regards,
Mac
bigmac wrote:Another possibility is to manipulate the PRM file, or vector table, so that special "pre-startup" code is run from the reset vector, which could set the required bus frequency. This code would then jump to the "traditional" startup code.
In a way, this is what is happening. Before the application software gets control, there is a reset handler that (a) initializes the PLL, and (b) checks if the application software is present.
If the application softwere is present, then reset handler does:
LDY AppReset
JMP 0,Y
to indirectly jump to the application's entry.
If the application is not present, it jumps to a boot loader program to allow flashing application software via CAN.
Anyway, as I said, the PLL is initialized before the application reset entry gets control. (sorry I forgot to mention this)
rlw wrote:In a way, this is what is happening. Before the application software gets control, there is a reset handler that (a) initializes the PLL, and (b) checks if the application software is present.
It's weird. You have 3 zeroout areas, less than 8kB in total. Inner ZeroOut loop is just two instructions, GSTAA and DBNE. That's only 6 bus cycles. Whole ZeroOut should take well less than 15ms at 40MHz bus clock..