[En-Nut-Discussion] Odd execution problem on the Ethernut3 after accessing the hardware RTC

[Douglas Pearless]

   Hello Matthias,

   I eventually found my problem, I was passing a bad pointer to a  
fprintf routine and that is why I had all of my problems!.

   Cheers Douglas.

   Quoting Matthias Wilde <ethernut at stockelache.de>:

> Hello Douglas,
>
> thanks to Michael Fischer I solved my problem. I had to erase the flash
> where before still the bootloader was stored. With empty flash everything
> went fine - now I can debug my application.
>
>
> Best regards
>
>
> Matthias
>
>
>>
>>
>>     I have a puzzling problem, I am using an ethernut3, an olimex
>> ARM-USB-OCD, Nut/OS 4.3.1, the latest version of Yagarto, Eclipse 3.2
>> and I have a MMC card in the slot (known working) and I have uart0
>> connected.
>>
>>     I have NUT/OS compiled with debug prior to this issue soin general
>> I can trace what is happening.
>>
>>     My code was working just fine and then I added code to access the
>> hardware RTC, by copying code from the ftpd example.
>>
>>     The first time I use a function that references uart0 (e.g.
>> fprintf(uart0,"here");) after I have called any routine to access the
>> hardware RTC (e.g. X12RtcGetClock ), if never returns from that
>> function.     The RTC is being correctly detected, date and time  
>> can be correctly
>> set and read from the hardware.
>>
>>     I closed eclipse and used insight directly to trace what was
>> happening and after single stepping through to the first function that
>> referenced uart0 and then either over or into that function (note all
>> the other code between those works fine) after calling X12RtcGetClock,
>> I had to use the STOP button to get control back, and I find that I am
>> always in a91init.c in a function called SpuriousEntry.     When I  
>> remove calls to the RTC, everything works fine.
>>
>>     If I move or remove calls that reference uart0 (which are either
>> fprintf(uart0,...) or fflush(uart0,...)), all code works until the
>> next fprintf(uart0,...) or fflush(uart0,...).
>>
>>     This seems rather wierd and I suspect I may have a memory
>> corruption, or perhaps the command I am passing the debugger at
>> initialisation are wrong (am I running out of space in memory? - how
>> can I tell?):
>>
>>     target remote localhost:3333
>> monitor reset
>> monitor sleep 500
>> monitor poll
>> monitor soft_reset_halt
>> monitor arm7_9 sw_bkpts enable
>> monitor mww 0xFFE00000 0x1000213D
>> monitor mww 0xFFE00004 0x20003E3D
>> monitor mww 0xFFE00020 0x00000001
>> monitor mdw 0xFFE00000 1
>> monitor mdw 0xFFE00004 1
>> break main
>> load
>>
>>     Any pointers, ideas or similar problems?
>>
>>     Cheers Douglas.
>>
>>
>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>
>
> --
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>