[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Uart lite hanging
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
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
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.
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/