Dear =?iso-8859-1?Q?Ricardo_Mart=EDnez?=,
In message !&!AAAAAAAAAAAYAAAAAAAAAJp7zGtD32xAi3bhcLYAeQ3CgAAAEAAAAOIGRX5gEblKkejr+11MkVQBAAAAAA==@teltronic.es you wrote:
I'm trying to printf something when one timer generates an interrupt.
Hm... there are certain things you can do in interrupt contect, amd certain things you cannot do.
Remember that in standard C you can in a signal handler only modify vailables of type sigatomic_t - you must not call any library functions, you must noit call any system calls. Well, in praxis you will probably find tat system calls are safe to call, and most library functions can be used as well - but nly when you know their implementation well enough to understand exactly what they are (not) doing.
Calling a printf() [which internally may need to allocate buffers, and thus call malloc() and a lot of other complex functions] is something you must never do ina signal handler.
Why do you think you can get away with the same here in U-Boot? Even in interrupt contxt, which is probably even more restricitve?
u-boot version is 1.3.4.
Old. OLD. I mean: OLD!!! Please update.
The problem is that when timer generates interrupt (reaches 0 after several cycles), I expect default u-boot code "do_irq", called from ".irq:" address defined in "start.S" get executed. In that function is where I want to printf anything to check it is working. But the whole system hangs. When timer generates the interrupt, ARM9 hangs without printing anything and normal execution is freezed.
printf and serial driver work perfectly because I've checked the steps above with prinft debugguing.
Is there any chance that the serial driver might be using interrupts, too, and that you run into some nested interrupt handling which is not or not correctly supported by U-Boot?
Best regards,
Wolfgang Denk