Reading NI-9065 CPU temperature with Xilinx xadc kernel module

[GBeaton]

I've compiled the Xilinx xadc driver in order to read the cpu temperature on my cRIO, and I find that it does not really play nicely with bitfile loading.

If the xadc module is already present when I call NiFpga_Open(), attempting to read the temperature (from /sys/bus/iio/devices/iil:device0/in_temp0_scale and/or in_temp0_offset) results in a kernel fault:

[   25.026847] Unhandled fault: imprecise external abort (0x1406) at 0x01d202b0
[   25.026851] pgd = dd600000
[   25.026863] [01d202b0] *pgd=1d669831, *pte=19b3375f, *ppte=19b33c7f
[   25.026875] Internal error: : 1406 [#1] PREEMPT SMP ARM
[   25.026917] Modules linked in: fuse ipv6 usb_f_eem g_ether u_ether libcomposite atomiczynqk(PO) nibds(PO) nikal(PO) xilinx_xadc industrialio_triggered_buffer kfifo_buf industrialio ci_hdrc_usb2 ci_hdrc udc_core
[   25.026929] CPU: 1 PID: 3019 Comm: app Tainted: P  O  4.6.7-rt14-ni-5.0.0f0 #1
[   25.026932] Hardware name: Xilinx Zynq Platform
[   25.026938] task: ded8ad80 ti: dd56a000 task.ti: dd56a000
[   25.026959] PC is at xadc_zynq_read_adc_reg+0xe8/0x108 [xilinx_xadc]

However if load my bitfile and wait for approx 1 second before loading the kernel module, I am able to read the CPU temperature reliably . If I don't wait long enough, the device hangs during module loading.

While this has largely worked for us, the fact that I need to jump through these hoops does not give me a lot of confidence in this solution. Does anyone recognise these issues, and is there another way to get the CPU temperature?

[GatorChomp]

Hi GBeaton,

My best guess after a cursory look is that the problem is due to the FPGA being programmed after your kernel module loads. If you use the NiFpga_Open() function, depending on the parameters it will reprogram the FPGA which *I think* will also reset the programmable logic portion of the device.

The reason this matters is that the cRIO-9065 uses a Zynq chip where the XADC components are actually part of the Programmable Logic/FPGA portion of the device. If you reset the FPGA, the kernel module will lose connection to the XADC hardware implementation. You would probably need to restart your kernel module after any reprogram with a sufficient wait. 

One thing that might be worth trying: NiFpga_Open() can be configured such that it won't program the device if the bitfile has already been downloaded. It's possible to download your bitfile to flash memory such that it's loaded onto the FPGA at power up. This might allow you to skip the reset/initial delay of the kernel module. 

Note that the bitfile will not run when it's initially loaded unless you configure it to in the bitfile build and you will have to tell it to run. That should only impact the LV FPGA code to my knowledge, and not the XADC portion since that's separate.

[GBeaton]

Thanks for the reply.

My understanding of the xadc agrees with yours. I had at one time considered flashing the bitfile to load at boot as you suggest, however we choose from a number of different bitfiles at runtime based on factors that change from time to time, so that isn't a practical solution for us.

Ideally there would be another mechanism for reading the CPU temperature that doesn't rely on the xadc kernel module, but I suppose as long as the delay is sufficient we can continue with that.