BGT60TR13C SPI comms issue, confusing timing diagram

[xcoder]

Hello,

We are struggling to to implement a reliable comms using this example for BGT60TR13C on our own custom board:

https://github.com/Infineon/sensor-xensiv-bgt60trxx

- For context we use push pull voltage translator like txs0108 between 1.8 and 3.3v, with stm32

- We had to bit bang the SPI to support seamless transition between 8bit and 12 bit FIFO mode.

- We are not convinced the timing of SPI matches the datasheet

- Small changes in clock delays will change how many test data frames are received correctly. For example if we bit bang with clock at 1uS we get 5 correct frames, if we bit bang with 2uS clock suddenly we got 45 correct frames. Supposedly it comes back with CLK_NUM_ERR bit set.

Further investigating with logic analyser it seems when in 8bit register mode, it changes the data on raising edge of clock, which we believe to be wrong according to the timing diagram 

Whilst in 12 bit FIFO mode

I've attached the Saleae Logic 2 logic analyser timing file, debug logs and radar config header file in a zip.

Thank You

[xcoder]

We just ntoiced if we ignore the CLK_NUM_ERROR we receive all 170 frames correctly. Whilst the bit is "flagged" still at random times depending on our SPI delay

[xcoder]

Another update, by increasing SPI speed to max I could whilst bit banging and getting rid of every delay possible. between packets and icnreaasing debug serial baudrate to 921600, for some reason it is still getting correct 140 000 frames. 

It's now bit banging at 543kHz, and width of clock pulse is 240ns

This doesn't make sense, I'd have expected slower SPI is more reliable before ramping up to maximum speed?
Am I missing something regarding the behaviour with the radar?

[Honey_D]

Hello @xcoder ,

Thank you for sharing the updates/outputs, while we are looking into all of your comments, can you please tell how can I help you? What is the exact solution you are looking for ?

Best Regards,
Honey

[xcoder]

if ((gsr0 & (XENSIV_BGT60TRXX_REG_GSR0_FOU_ERR_MSK |
XENSIV_BGT60TRXX_REG_GSR0_SPI_BURST_ERR_MSK |
XENSIV_BGT60TRXX_REG_GSR0_CLK_NUM_ERR_MSK)) == 0U)

Any ideas why would that be the case? The data is still valid in the buffer, or is the intention to clear FSTAT register and restart?

Regardless, the error wasn't CLK_NUM_ERR it was buffer overflow, which explains why giving all the speed we could it seemed to start to work out of nowhere, since we were able to read the data out faster than it was filling.

 Still not sure why register reads, change MISO line on raising edge of clock. But further investigation shows that is only being done on first byte, not the next 3 which is where the ifnromation about register is stored.

[xcoder]

Further looking through the code provided by infenion

/* Fields of register GSR0 */
/* ------------------------ */
#define XENSIV_BGT60TRXX_REG_GSR0_FOU_ERR_MSK           (0x01UL)     /*!< FOU_ERR: msk */
#define XENSIV_BGT60TRXX_REG_GSR0_MISO_HS_READ_MSK      (0x02UL)     /*!< MISO_HS_READ: msk */
#define XENSIV_BGT60TRXX_REG_GSR0_SPI_BURST_ERR_MSK     (0x04UL)     /*!< SPI_BURST_ERR: msk */
#define XENSIV_BGT60TRXX_REG_GSR0_CLK_NUM_ERR_MSK       (0x08UL)     /*!< CLK_NUM_ERR: msk */

The XENSIV_BGT60TRXX_REG_GSR0_CLK_NUM_ERR_MSK mask I believe is wrong. So is XENSIV_BGT60TRXX_REG_GSR0_FOU_ERR_MSK. 

This is how it is defined in datasheet

[Honey_D]

Hello @xcoder ,

Since the example code you are referring to is specific to the available CSK kit, can you please few more information with us :

1. What all components does your custom board consists ?
2. Can you share the entire project with us to understand it more clearly

if ((gsr0 & (XENSIV_BGT60TRXX_REG_GSR0_FOU_ERR_MSK |
XENSIV_BGT60TRXX_REG_GSR0_SPI_BURST_ERR_MSK |
XENSIV_BGT60TRXX_REG_GSR0_CLK_NUM_ERR_MSK)) == 0U)

Regarding the above mentioned condition, the register GSR0 is used for monitoring the FIFO error as mentioned in datasheet section 3.7 Global Status Register. https://www.infineon.com/dgdl/Infineon-BGT60TR13CDataSheet-DataSheet-v01_00-EN.pdf?fileId=8ac78c8c7d... 

Best Regards,
Honey

[Honey_D]

Hello @xcoder ,

I hope the query is been resolved from your end. We are closing the thread due to inactivity, please create a new one for further information

Best Regards,
Honey