This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530: SPI read U1DBUF error.

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK,

Hi team,

Here's the request from the customer:

In SPI mode, reading U1DBUF is always 255 and adding a delay before reading leads to a direct crash.

Customer is using IAR version 8.10 and without using Z-Stack. They connected the CC2530 to the BMP280 air pressure sensor via SPI, the CC2530 is in the master mode, and the BMP280 is in the slave mode, and the sending data is normal (observed the MOSI waveform with an oscilloscope).

However, reading sensor data is always wrong, the program is as follows:

while(1)
{
P1_4 = 0; //Chip select
U1DBUF = 0xD0; //Send BMP280 Chip ID Register Address, read Mode
while( !U1TX_BYTE ); //Wait for transmission to complete
U1TX_BYTE = 0; //Clear the flag bit
//Delay_us(70); //Eight clocks
chip_id = U1DBUF; //Read the BMP280 chip ID
P1_4 = 1;
sprintf(strTemp, " id: %d", chip_id);
LCD_TextOut(0, 1, strTemp);
}

This program always reads chip_id of 255.Observe the MISO waveform with an oscilloscope with only one negative pulse, then chip select P1_4 is pulled high.It is clear that the CC2530 does not get MISO data. If uncomment "Delay_us(70);", that is to add a delay, so that SPI has enough time to receive MISO data, then the program is locked, it seems that the data of U1DBUF has not been received completely, and has been waiting. No matter how long the delay is, or judge U1TX_BYTE (received data ready flag), the program is locked. In this locked state, the oscilloscope cannot watch the MISO waveform.

Could you help check this case? Thanks.

Best Regards,                                                       

Nick

  • Hi Nick,

    Is Delay_us a while/for loop or does it put the CC2530 device into a low power mode?  If in a low power mode then the USART peripheral is likely not being allowed access to the clock it needs to drive the SPI lines.  Can they provide oscilloscope images and confirm that the timing corresponds to the expectations from the BMP280 datasheet?  Also, the CC2530-Software Examples and Z-STACK software resources both contain SPI layers which can be repurposed for the customer's needs and should be further reviewed.  They likely need to check the RX_BYTE bit from U1CSR and drive the SPI lines once more after sending the BMP280 Chip ID Register Address in read mode so that the buffer can actually be filled with received data.

    Regards,
    Ryan

  • You should refer to LCD driver related code as the followings and make sure you call XNV_SPI_WAIT_RXRDY before XNV_SPI_RX (reading U1DBUF)

    /* ----------- XNV ---------- */
    #define XNV_SPI_BEGIN()             st(P1_3 = 0;)
    #define XNV_SPI_TX(x)               st(U1CSR &= ~0x02; U1DBUF = (x);)
    #define XNV_SPI_RX()                U1DBUF
    #define XNV_SPI_WAIT_RXRDY()        st(while (!(U1CSR & 0x02));)
    #define XNV_SPI_END()               st(P1_3 = 1;)