DE10-Lite accelerometer with NIOS using University Program IP

[Altera_Forum]

I have a number of students who would like to use the DE10-lite accelerometer for their class projects. We cannot seem to get this working within the NIOS system using the University Program "Accelerometer SPI Mode" (3 wire spi) block. When opening the accelerometer device in Eclipse it provides a non-NULL pointer, implying the device is getting opened. All reads return a value of 0. No way to know if writes are working. No errors indicated anywhere in the creation or execution process. 

 Has anyone gotten this to work?  Qsys, top level block, and simplified code attached  Thanks in advance  tj - Assoc Prof of ECE - currently letting his students down!   https://alteraforum.com/forum/attachment.php?attachmentid=14228&stc=1 https://alteraforum.com/forum/attachment.php?attachmentid=14228&stc=1 https://alteraforum.com/forum/attachment.php?attachmentid=14229&stc=1

[Altera_Forum]

Hi qtj000, 

 Apologize in advance since I’m not an expert in NIOS application. Did you check if there is an output clock from the ALTPLL itself? From the screen shots, there is no areset conduit at the ALTPLL component in the Qsys. The ALTPLL requires the areset to be pull to low all the time. If there is no output clock from the ALTPLL itself, then surely there is no input clock to the accelerometer IP in order for the IP itself to be running.   Regards, nyusof (This message was posted on behalf of Intel Corporation

[Altera_Forum]

We typically instantiate the PLL without the asyc reset. If not intantiated it has no wire and is not necessary. I do have a PLL clock output.

[Altera_Forum]

All I can say really is welcome to University Program IP cores. For the DE1-SoC board we use for teaching, I've ended up rewriting the majority of the IP cores for the DE1-SoC computer design because the quality and reliability of the IP cores provided is simply appalling. 

 Getting a non-null pointer in Nios doesn't mean anything about the external hardware, it just means that there is a base address defined in the board support package. Even if you didn't connect the external pins of the IP core, you would still get a non-null pointer.  As for the PLL not having a reset, it will likely not cause a problem. It just means it can't be reset after a loss of lock, not ideal, but functional. To be honest all of the Altera and Terasic sample designs don't bother with the reset either, so clearly they pay a lot of attention in there designs.   If you haven't already, make sure you set timing constraints on the IO pins for the SPI. You could be getting timing issues on the SPI lines. You can check this by analysing the lines with an oscilloscope.  You could also try not using the PLL at all. Assuming Nios is running from a 50MHz clock, feeding a 50MHz clock into the clock pin of the accelerometer core will give an SPI rate of 3.125MHz which is within the 5MHz limit for the AXDL345. Fewer random bits of Avalon-MM fabric will probably help.  ---  As an alternative, scrap that core entirely. The "SPI 3 Wire Serial" core in Qsys (Interface Protocols/Serial), is one of the few cores that does seem to work properly in my experience. If you set it to:  - data width: 16 - clock phase: 1 - clock polarity: 1 - shift direction: MSB first - number of slaves: 1 - spi clock rate: 1000000 (1MHz)   Leave the rest of the parameters as default values. You won't need a separate PLL. Just connect it to the same clock as the Nios processor. It has an internal clock divider.  From a code stand point, you would now simply send 16 bit data words from Nios that are: "((read << 15) | (address << 8) | (data))".