[En-Nut-Discussion] NutGetCpuClock() sometimes does not work.

[Harald Kipp]

This is indeed a bug. find an earlier report below.

In the CVS HEAD a reserved area had been added to nutinit.c.
But timer.c doesn't make use of this right now.

Note that printf's for AVR platforms may consume a lot of
RAM unless you place the format strings in FLASH memory.

Harald

------------------BUG REPORT ----------------------------------------


Initial Comment:
When developing an application for the ethernut2 I made
exessive use of debug-printf's which used a huge amount
of initialized RAM. From a certain point the setting of
baudrates for usart0 and usart1 failed. The function
NutGetCpuClock() returned 12.28MHz instead of the
correct 14.7MHz which made the baudrates about 1.2
times faster than what they should be. My theory (could
not proof it so far) is that the variable ms62_5 in
timer.c is moved from internal to external RAM which
makes the access slower and so the calculated cpu-speed
is not correct.

----------------------------------------------------------------------

 >Comment By: Harald Kipp (haraldkipp)
Date: 2004-06-29 18:17

Message:
Logged In: YES
user_id=303906

I fully agree, that's indeed a real problem.

There's a similar issue when trying to use PORTA/C.
Nut/OS should get some reserved space, which is
guaranteed internal RAM.

Many thanks, Christian.

----------------------------------------------------------------------


At 15:07 05.11.2004 +0000, you wrote:
>Hi,
>
>I found that NutGetCpuClock()  report backs the wrong clock frequency 
>12285280 instead of 14742560. As a result uart0 stops working as it is set 
>to the wrong baud rate.
>
>I have two programs, one works and the other does not. However both 
>programs are executing EXACTLY the same source code. The ONLY difference 
>between the two is that I have linked in my full application (even though 
>it is NOT being executed) for the program that does not work. However the 
>cut down program with out my full application does work.
>
>I fixed the problem by patching NutComputeCpuClock() so that it does NOT 
>compile the asm method of calculating the clock speed.
>
>Yes, I have checked that the large program is not overwriting any memory 
>locations.
>
>For those of you that are interested here is the output from the two 
>different programs.
>
>**** FAULTY OUTPUT ******
>D..iW..Y.xY. at f+..c..]P.;]c...b.-.KVe(.
>Now the baud is correct
>NutGetCpuClock() = 12285280
>
>**** CORRECT OUTPUT ******
>Nut/OS 3.4.3.1 NUT TEST - WRONG BAUD RATE...
>
>Now the baud is correct
>NutGetCpuClock() = 14742560
>
>
>And here is the IDENTICAL source code
>**** IDENTICAL SOURCE CODE FOR BOTH CASES ******
>int main(void)
>{
>    u_long baud = 38400L;
>
>    /*
>     * Initialize the uart device.
>     */
>    NutRegisterDevice(&devDebug0, 0, 0);
>    freopen("uart0", "w", stdout);
>    _ioctl(_fileno(stdout), UART_SETSPEED, &baud);
>    NutSleep(200);
>
>    printf("\nNut/OS %s NUT TEST - WRONG BAUD RATE...\n", NutVersionString());
>
>    fflush(stdout);
>
>    NutSleep(2000);
>
>    // A quick fix to correct the baud rate;
>    UBRR0L = (u_char) 23;
>
>    printf("\nNow the baud is correct\n");
>    printf("NutGetCpuClock() = %ld\n", NutGetCpuClock());
>
>    fflush(stdout);
>    NutSleep(2000);
>
>    // Halt here
>    while (TRUE)
>        ;
>    return 0;
>}
>
>Any ideas as to the problem?
>
>May be NutComputeCpuClock() should be changed so that in future it does 
>not try to calculate the clock frequency dynamically.
>
>Your Louis B.
>
>_________________________________________________________________
>It's fast, it's easy and it's free. Get MSN Messenger today! 
>http://www.msn.co.uk/messenger
>
>_______________________________________________
>En-Nut-Discussion mailing list
>En-Nut-Discussion at egnite.de
>http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion