Unhandled Exception when performing _io_fflush() to UART

[panpwr]

Hello,

I try to sent a short string (4 bytes) to UART, at the following way:

_io_write(uart_ch, stream_ptr, stream_len); //<== After performing this line, only 2 bytes are actually transffered to UART

_io_fflush(uart_ch);  // <== Unhandled Exception

I use Keil uVision4 (4.60) IDE. It doesn't matter how I open the UART - it's the same result (either XON_XOFF or NON_BLOCKING modes).

When I check the debug->MQX->Check for errors, I see under "Tasks": "Unhandled Exception", the Task ID, and the Task Descriptor (by the way - it's not the task that issued the UART write action, but a different task).

1. Why doesn't it write all the bytes at once?

2. What can cause the "Flush" action to behave like that?

3. What can I do with the exception information? How can I get to the bottom of the problem (I have very little knowledge of MQX debugging...)

Thanks,
Lior

[c0170]

Hello panpwr,

please read this thread about unhandled exception : MQX UNHANDLED INTERRUPT . Function which might help you is  _int_install_unexpected_isr(). Check also MQX reference manual for more information.

What's your board and which driver do you use (int or polled)? Step into _io_fflush (fio/io_fflush.c. If you skip fflush function, does it invoke unhandled exception as well?

Regards,

MartinK

[panpwr]

Hello Kojto,

I have the _int_install_unexpected_isr() already installed, but I didn't quite get how can I use it (i.e., nothing is printed to console).

My custom board is based on the TWR-K60D100M. I use interrupt mode. When not using the fflush function, it doesn't oocur, but only on the next writing to UART.

Also, I've found something else, pretty weird - When I write a constant string (not from a variable) to UART (it works fine!), and afterwards the variable (which didn't work so far) - It suddenly works fine with no exception!

[c0170]

Hello panpwr,

due to not having any fault with the constant string , this gives you a hint about a problem. It dwells in with _io_write parameters.  You might pass there address which is stacked and it might get destroyed and fflush still wants to access that address therefore it generates fault.

Please debug the code and check addresses of parameters :smileywink:

If unexpected_isr does not print anything, does your console print anything ,for instance hello world example? Anyway, you dont need a console to find out the cause. There are few threads dedicated to unexpected_isr and how to find out which fault did trigger it.

Regards,

MartinK

[panpwr · Accepted solution]

Hello,

After a long assembly level debugging (:smileyshocked:), I've found that the stack pointer of the current task, just before leaving the fflush -  points to a an area which is a different task's stack! (though I've used Keil's stack monitor, and haven't seen any shortage of stack memory for this task).

I've enlarged the stack size for this task and the problem went away (I hope it won't appear again in a different location:smileywink:).

Another small question regarding the unexpected_isr:

I do use printf() to print to console - so I would expect to see more information once an exception has been triggered. I must say that I haven't quite got the idea of how to debug such cases with my Keil's uVision (Keil support usually do not support MQX debugging issues....).

Thanks!