Sauraen Posted November 23, 2013 Report Share Posted November 23, 2013 I'm working on inter-LPC17-core communication via MBNET. It's going pretty well, I have MIDI messages generated from front panel events detected by one core being sent to and received by another core. However, for this other core, it works fine for only about 23 seconds. During that time, it connects to MIOSStudio, I can upload new code, etc., and see it telling me in debugging messages that it's receiving correct MBNET data from the other core. Then, after about that much time, when it receives another MBNET event, it instantly stops responding to MBNET as well as MIOSStudio (it labels it as "MIOS32*" in the menu, and it won't connect), and the light on the LPCXPRESSO board blinks with a frequency of about 2 Hz (no PWM, actual blinking). When I power-cycle the core it works for another 23 seconds or so. If I don't send any MBNET data, it just sits there working fine (and responding to MIOSStudio), but if I send any MBNET data after 23 seconds after turning it on, it immediately hangs up like this again. It's something about my code, but not something obvious (i.e. I didn't program the light to flash like that!). When it's running the MBNET test program, it continues to work for at least a few minutes, continually receiving MBNET data and showing it via MIOSStudio. However, to make the code for this core, I just copied-and-pasted the code from the other (sending) core, and modified it in seemingly non-essential ways. It looks like it's hanging up after completing the scan of MBNET nodes, because that's about as much time as it takes to scan the nodes when running the test program; but the fact that it works during the scan, then fails at the end, and fails in such a way that it disables USB and starts the status light flashing is a complete puzzle to me! This has got to have been programmed as a "crash state routine" for the CPU to enter under certain conditions, but I don't know how I got it into that state. Quote Link to comment Share on other sites More sharing options...
TK. Posted November 23, 2013 Report Share Posted November 23, 2013 I guess that the exception handler has been entered. On certain failures it's still possible to output the PC at which the CPU trapped over USB. If not, you should at least see the PC on a LCD (-> connect a LCD for debugging) Once you know the PC, you can search in the project_build/project.lss line for the appr. function. A typical exception would be an access to a NULL pointer Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Sauraen Posted December 1, 2013 Author Report Share Posted December 1, 2013 Thanks TK, it was a null pointer. :) I was not expecting such a small processor to have such a sophisticated hangup detection routine! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.