Strange LPC17 hangup from MBNET

[Sauraen]

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.

[TK.]

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.

[Sauraen]

Thanks TK, it was a null pointer. :) I was not expecting such a small processor to have such a sophisticated hangup detection routine!