What is causing Kernelpanic on Blackfin?

[Stranman]

I get the following after trying to run debug code on a Blackfin 537 target:

Processor Status = Halted

Location: _KernelPanic + 0x0

Any idea how to troubleshoot or resolve this error?

-P

[G-Money]

Stranman,

1. What is your code doing? Can you post it here?
2. Can you run any of the shipping examples correctly (like BF537 LED Test.lvproj)?

Kernel panic can be caused by a lot of things and unfortunately that error message wasn't very descriptive. If you could post your code or explain a little bit about what you're doing then we might be better able to help. Also, make sure that you can run a shipping example for a sanity check on the hardware. Thanks!

[Stranman]

Well, I've narrowed the problem down.  KernelPanic happens when the serial port receives continuous data.

Attached to the serial port is a sensor that when in continuous mode outputs 67 bytes @ 100 Hz (Port settings: 115200-8-N-1)

Currently, I'm using the serial compatibility vi's and polling the port every 10 ms.

I'm  having trouble getting the BF UART vi's to work properly.  Maybe this will solve my problem? 

Is it possible to use the BF UART vi's in a polling fashion rather than in a callback?

If so, can somebody post a code snippet?  I've tried all types of implementations w/ the UART vi's to no avail.

Thanks,

-P

[G-Money]

Stranman,

          What issues are you having getting the BF UART VIs to run? Post your code so we know what you are doing. I'm pretty sure you can poll the UART VIs. Did you check out the SPI and UART.lvproj shipping example? While this shipping example shows off simultaneous reading/writing on those lines, the UART was writing just in a loop (polling of sorts). Here is also another forum thread discussing BF UART architecture (http://forums.ni.com/t5/LabVIEW/Blackfin-UART-Interrupt-Callback-for-receiving-data/m-p/503303?requi...).

[Stranman]

Ok, so after some more digging.  It appears the Serial Compatibility driver use is not causing the KernelPanic.  I still have questions on the BF UART vi usage though.  I'll start a new thread for that.

I'm now inclined to believe that the SDCard writing is causing the KernelPanic.  After some benchmarking the write cycle is much longer than originally thought.  I'm guessing this could cause a KernelPanic?

[G-Money]

Stranman,

        Which png image is the one giving you the KernelPanic? If it is the first one (SerComp Tx-Rx.png), what happens if you add like a 10 millisecond wait between the write and read?

[Stranman]

The code that yields a KernelPanic is not any that I posted.  They were my baseline test cases, which led me to believe that it must be caused by the SDCard writing and the manufacturer's drivers to handle this operation since the write cycles are much longer than I had expected after benchmarking.

[G-Money]

Stranman,

          Could be. I would try isolating the SDCard code and seeing if the KernelPanic goes away if you take that code out. Thanks for the clarification.

[Stranman]

Yes, I've already done that.  That's why I'm most inclined to believe its SDCard related.

Thanks for helping.

Regards,

Paul

[Stranman · Accepted solution]

Solution: KernelPanic only occurs when program is started while data is coming in over the serial port.

If sensor is idle until program start -> runs w/o a hitch.  Program sets sensor into active mode to Tx data.

If sensor is active and Tx'ing data to serial port of Target on start-up-> KernelPanic!