I tried to run the following code with SPI and communicate with MSP432 (slave). The slave will return 4 bytes back which are: 0x55, 0x0F, 0xF0, 0xC3. And I saw the MOSI and MISO signal on o’scope and the signal showing correctly. However, there is no data in dat_in when I checked the watch window (all shown 0xFF). Can you give me some suggestions? Thanks.
#define SPI_RX_PORT SPI_RX_PC
#define SPI_CLK_DIVISOR 100
#define SPI_CLOCK_MODE 0
#define CLOCK_PORT B
#define CLOCK_BIT 0
WrPortI(PCDR, &PCDRShadow, RdPortI(PCDR) | 0x10); // initial Tx idle high
WrPortI(PCDCR, &PCDCRShadow, RdPortI(PCDCR) & 0xEF); // push-pull drive control
WrPortI(PCDDR, &PCDDRShadow, RdPortI(PCDDR) | 0x10); // output direction
BitWrPortI(PCDDR,&PCDDRShadow,0, 5); // input //
WrPortI(PCAHR, &PCAHRShadow, RdPortI(PCAHR) & 0xFC); // select PC4 TXB altenate
WrPortI(PCFR, &PCFRShadow, RdPortI(PCFR) | 0x10); // enable alternate function
BitWrPortI(PCDR, &PCDRShadow, 1, 2); // CS high
cmd = 0x55;
cmd = 0xF0;
cmd = 0x0F;
cmd = 0x3C;
BitWrPortI(PCDR, &PCDRShadow, 0, 2);
SPIWrRd(cmd, dat_in, 4);
BitWrPortI(PCDR, &PCDRShadow, 1, 2);
I also tried to use SPIWrite for transmitting a single byte command. Then using SPIRead for reading back 4 bytes data. However SPIRead also have no data read back in DestAddr.
I tried to config the register SBCR to 0x0C.
- Is this config value correct?
- Is this SBCR readable? I tried to look at the Memory Dump window at 0xD4, it shown 0x00 even after I set it to 0x0C. I created an int to try to read the value:
WrPortI(SBCR, &SBCRShadow, RdPortI(SBCR) | 0x0C);
temp = RdPortI(SBCR);
The value of temp show 0x28 which is different with what I set and the config will be “Disable the receiver input”.
Please make sure you have the latest Dynamic C I2C libraries. Start with any version of Dynamic C 10.72 and follow the instructions in the Git repository (https://github.com/digidotcom/DCRabbit_10) to update the libraries and samples.
I recommend trying to use the libraries to initialize the I2C peripheral and send/receive data. Take a look at the existing I2C samples to see how they work.
Let me know if you’re still having trouble after looking at those samples and I’ll look for possible problems with the code you posted.
Found that after running readUserBlock(), the register value SBCRShadow is taken in spiInit() in line 460-463. Then port D is configured to be input rather than port C in SBCR.
In my case, the spiInit() is run after readuserBlock(), so this is the reason of no data received into SPI buffer.
- Why SBCRShadow is not initialized to 0 in spiInit?
- What is the purpose of line 460-463 in spiInit?
Sorry for getting your SPI question mixed up with recent changes to the I2C code – they’re unrelated.
For some of your questions:
It’s likely that SBCR isn’t readable, so you should make use of SBCRShadow, a local variable that shadows the last value written to SBCR.
WrPortI(SBCR, &SBCRShadow, SBCRShadow | 0x0C);
SBCRShadow is initialized somewhere else, and if you consistently use it in your WrPortI() calls, it will stay up to date with the last value written to SBCR. Read up on “shadow registers” in the Dynamic C documentation for more details on how they’re used.
The line “i = ( i &~0x0C ) | SPI_MS;” clears bits 2 and 3 (i & ~0x0C) and then sets them with the value of SPI_MS (which is either 0x08 or 0x0C).
The problem you’re running into is that the RCM6700 uses serial port B for SPI communications with the serial flash that holds firmware and UserBlock information. You should use one of the other serial ports for your SPI interface to the MSP432.
As mentioned in an inner comment, you should avoid using serial port B because the RCM6700 uses it for its serial flash.
If you use another serial port, you shouldn’t need to use any of the WrPortI() and BitWrPortI() calls because SPIInit() will do all of that for you.