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

[Matthias Wilde]

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


--