Link Copied
Hi Nitin123,
Based on your comment, it should be safe to assume that:
- the Nios II is online & working
- the SPI HAL driver is present & can access the SPI Core soft IP
- the IO is working fine (Observed SPI transaction on the bus line)
With that, I would suggest comparing the observed SPI transaction with the MCP2515 sample waveforms.
And check if there are any differences.
For example,
With this Read Instruction, failure may be caused by:
- nCS line is not at logic ‘0’ level throughout the whole SPI transaction.
(Especially when there are multiple SPI agents, and the SPI Core soft IP might select the wrong nCS line) - Instruction sent in SI line is invalid.
- Address Bytes sent in SI line is invalid.
- SCK clock cycles ends prematurely.
Besides that, please review the following SPI Core settings in your design.
Altera’s SPI Core supports all SPI Modes.
The MCP2515 supports Mode 0,0 & Mode 1,1 only.
Regards,
Hello Sir,
Thank you for your prompt response.
This is the timing diagram from my logic analyzer, which confirms that the chip select (CS) line remains low throughout the entire SPI transaction. Each command, address, and data byte is transmitted in 8-bit segments. There's an observed delay of approximately 11.8 µs between bytes, which, according to various sources, is within normal expectations. The SPI clock operates continuously during each 8-bit transfer, and the CS line stays low for the full duration of the transaction, encompassing command, address, and data phases.
In my Qsys design, the SPI clock was initially set to 10 MHz but now it is 1 MHz : MCP2515's maximum supported frequency is 10 MHz. Additionally, SPI mode 0,0 has been selected, as supported by the MCP2515.
I have two specific concerns:
1. Chip Select Behavior: Initially, I used the macro:
IOWR_ALTERA_AVALON_SPI_SLAVE_SEL(SPI_BASE, SPI_SLAVE_SEL);
However, this caused the chip select line to toggle every 8 bits. To address this, I switched to using the alt_avalon_spi_command function, which maintains the chip select line low throughout the entire transaction, ensuring proper communication with the MCP2515.
2. Utilizing HPS CAN Controller Without DDR: Our custom Cyclone V SoC board lacks DDR memory, preventing the use of a full-fledged embedded Linux system. I'm considering leveraging the HPS-side CAN controller by writing a bare-metal program that operates from the internal SRAM (approximately 64 KB). Is this approach feasible given the memory constraints? If so, could you provide any sample programs or guidance on implementing this?
Now for mcp2515, I believe the software setup is correct, but to rule out hardware issues, I've ordered additional MCP2515. Any insights or sample code you can share would be immensely helpful.
Thank you
Hi Nitin123,
Thanks for reviewing the waveform and agree with your statement that the SPI transaction looks healthy.
To answer to your concerns:
- Chip Select Behavior:
Yes, you are correct to apply the alt_avalon_spi_command function.
It is recommended when you are not planning to write your own drivers. - Utilizing HPS CAN Controller Without DDR:
Sorry, but we don’t have a MCP2515 setup to run this.
We are applying our experience of interacting SPI Host soft IP with other SPI peripherals to support your use case.
- Concern on Hardware Issue
Agree, that is a valid perspective to take account of.
Since the SPI transaction from Master looks valid, we should investigate from the Slave too.
Here are some MCP2515 traits that you might be interested:
(Note that, we strongly advice to approach Microchip on debugging MCP2515.
Our expertise is up to generic SPI transaction only, and also new to the MCP2515.)
- Write-Readback experiment
Have you tried Read back the same MCP2515 0x31 address?
Or run a simple write-readback experiment on any MCP2515 control register when under Configuration Mode? - Configuration Mode upon power-up & Normal Mode
Could it be possible that you need to switch to Normal Mode before using any of the TX Buffer? - LOAD TX BUFFER instruction
There is a dedicated instruction that writes to address 0x31,
Please give it a try too.
Hi Nitin123,
Currently, the read operation is failing every time after entering configuration mode and also in normal mode.
When I try to verify what I have written, it is not matching — even the timing registers CNF1, CNF2, and CNF3 are reading back as 0xFF.
Answer:
When you mentioned “not matching”, is it all 0xFF? Or there are other values?
- If all read attempts returns 0xFF, it is possible the MCP2515 is not powered on.
- If some read attempts returns valid value, then the MCP2515 is powered on.
The SPI SO line is High-Impedance (aka logic “1”). So, it is likely that the no Data Out is detected on the SO line.
Could you kindly verify if my write and read operations are correct?
Answer:
The write_reg is correct.
As for read_reg, I would imagine the following SPI transaction with your read_reg, which is different from the MCP2515 recommended waveform.
I would suggest this instead:
static uint8_t read_reg(uint8_t addr) {
uint8_t tx_buf[2] = {MCP_READ, addr};
uint8_t rx_buf = 0;
alt_avalon_spi_command(SPI_BASE, SPI_SLAVE, 2, tx_buf, 1, &rx_buf, 0);
return rx_buf;
}
Quick tips :
Using the logic analyser, you can double-check the read_reg() and tinker around its argument until you get the exact same SPI transaction from MCP2515.
- Manual Chip Select Control
Could you please clarify why this behavior is happening?
The CS toggling is an expected behaviour.
You can replicate this behaviour by giving the flags argument - ALT_AVALON_SPI_COMMAND_TOGGLE_SS_N to alt_avalon_spi_command().
Quick tips :
If you are writing custom SPI driver, perhaps you can take reference from the alt_avalon_spi_command().
For example, about how to not toggle CS:
- Utilizing HPS CAN Controller Without DDR
As a general procedure, I would suggest taking a known good working Uboot implementation that contains CAN, and strip it down to just only the CAN portion. i.e. take out everything including any DDR setup. It might fit within the HPS OCRAM.
