Re: [microblaze-uclinux] Uart lite hanging

[Giulio Mazzoleni <giulio.mazzoleni@xxxxxxxxxxxxxxxxxxxxxxx>]

Hi Olof,
looks like your are taking this problem very seriously!
Sorry for not having replied earlier.

> If you look in the System.map file, what function will the address $1e08 correspond
> to? If your map is close to mine it looks like _user_exception(). But I don't know
> yet if that's just the function that gets called when doing remote debugging (single
> step et all).

In my System.map I have

44001d7c t restore_context
44001e20 T _reset
44001e30 T _user_exception

I usually let the application run as normal and connect with gdb only
after having reached an hang with gdbproxy --attach pid, so I would
exclude a problem related to the use of the debugger.

> I'm currently investigating this and it looks like
> it's not the uartlite driver to blame but the memory allocation
system.

I agree with you. As already written some posts ago I tried replacing
the original uartlite driver with a completely new custom one (and very
badly written - this is why I have not posted it yet), using the proc
filesystem as input/output to userland applications.
Strangely enough I could crash my test application in the usual way and
on the same address.

> It seems harder to encounter the hang if the sprintf statements are
removed.

Well, I don't know if it is impossible. What I can say is that if I put
a call to sprintf, pow, exp (these are what I tried) I could crash the
application very easly. I was not able to do the same without that call.

I'll try to apply the gigantic patch, even if I could not find it yet.

I really appreciate your effort in investigating this problem.
Many thanks,

Giulio Mazzoleni

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/