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

[Matthias Wilde]

Hi Douglas,

I am running in a similar behaviour. If my code executes NutSleep my
debugger hangs. Does NutSleep is OK on your system?
I use the same environment just instead 4.31. I use NutOS 4.2.1.

My feeling is that might be the same problem???

I heard that a debugger should somehow "triggered" all the time, but I
have no idea if that is true and if how I can manage it...

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


--