time zeroing RAM in start12.c

[rlw]

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.

[kef]

But 40MHz bus you have after initializing PLL, which happens probably after ZeroOut? What is your oscillator clock? 4MHz?

[bigmac]

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

[rlw]

---

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)

[kef]

---

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..