Hey everyone, just wondering if you could perhaps point me in the right direction.
I'm doing a project using an ARM7 lpc2388 using RTX and the TcpNet library for TCP ethernet communication. I found my system would seemingly randomly stop and become unresponsive. This was previously masked by the fact that I have a WDT in place and this would force the system to restart. I thought it was a timing issue but when I stop the ARM7 in the debugging environment I see that it throwing a data abort exception (stops at the Dabt_handler). When I look at the task list it shows the task that I have handling all the TcpNet call in an underflow state.
I'm not sure how I can debug this. What sort of bugs could I have that could cause this? I'm not touching any assembly stuff in my code. Could it be because I'm calling the TcpNet timer tick from an interrupt? I'v noticed that it only seems to happen when my system is being stressed quite heavily. Could this be caused by the interrupt fifo overflowing? I've never really encountered this type of random problem before so I'm kind of at a loss on how to proceed.
Any thoughts would help!
Mark
You said: I put it into a timer interrupt since the function reference seems to say you can.
That is very interesting. I'm reasonably sure that the documentation has changed for that because it used to give an example of using a separate dedicated task to periodically call the timer_tick function. I know from some previous communication with keil technical support that all the function does (or did at the time) was set a flag that was picked up during the call to main_TcpNet, so it could even then have been called from an ISR. But then they said that you shouldn't because they might change the implementation details.
But you're obviously right about calling os_ functions in an ISR. Even now that is a documented no-no.