Announcements

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
frangargiulo
Level 1
Level 1
5 sign-ins First solution authored First reply posted

Hi,

We started a while ago working with the BGT60TR13C development kit to follow the suggested learning curve before jumping into our own design. We have already tried some succesful configurations by using the dev kit and Radar Fusion GUI, so now we have moved to our own PCB, where we have a dedicated host MCU (instead of the one from the Dev Kit).

The SPI communication in our board between the host and the radar works as expected, as also does the initialization (get device id to verify not only that the radar is connected but also that it is a BGT60TR13C, amongst other steps). Just for some context, we are also following the guidelines provided in Inifineon's repository (https://github.com/Infineon/sensor-xensiv-bgt60trxx). We are also using the default presence settings configuration parameters provided with the SDK.

So far so good... except that there was no way of getting data into the FIFO, it constantly reports as if it is empty. We focused on using the data test mode, to discard any issue with the configuration, but still in the data test mode (SFCTL:LFSR_EN= 1B), the FIFO is never filled.

We are following the same sequence as the one implemented in https://github.com/Infineon/sensor-xensiv-bgt60trxx and double checked it also with the one described in the datasheet (10.Enhanced Functions->10.1 Data Test Mode).

Any clue were the issue could be? Is there any other step needed to make the test mode work that is not documented in the datasheet? We are running out of ideas here, so we would really appreciate any help anyone could provide.

Thanks in advance.

1 Solution
frangargiulo
Level 1
Level 1
5 sign-ins First solution authored First reply posted

@Deepa_V we've found a bug in our implementation. While doing the configuration, we were not properly setting the right amount of register values available in the register array, hence probably were overwriting some other values that ended up with this undefined behavior.  The FIFO is now getting filled as expected. Thanks for the fast reply.

View solution in original post

0 Likes
3 Replies
Deepa_V
Moderator
Moderator
Moderator
First comment on KBA 50 likes received 250 replies posted

Hi @frangargiulo ,

Can you please share your register configuration for a better understanding of the issue? Also, Please let us know your SPI frequency and the GSR0 register value. 

Best Regards,

Deepa

0 Likes
lock attach
Attachments are accessible only for community members.

Hi @Deepa_V ,

Yes, for sure. We tried with many different configurations, but in order to narrow down the problem, we have decided now to use only the same configuration as the one provided in https://github.com/Infineon/sensor-xensiv-bgt60trxx/tree/master, as we are also targeting a presence application in this stage. Attached you will find the corresponding configuration json file, along with the .h file containing all the registers generated by the bgt60-configurator-cli tool (I had to change the extension to .c in order to be able to upload, but it is exactly the same file generated by the tool).

Regarding your two other questions:

  • SPI Frequency: 20MHz. Already tried with different frequencies, and verified signal integrity under oscilloscope, but FIFO still remains empty.
  • GSR0: Is it really relevant in this case? Right now we are triggering everything so that we can at least see that the number of elements in the FIFO starts to grow. We are not doing any FIFO burst read yet, as it really makes no sense.

Also, I would like to understand how the test mode works. Right now we want to test the end to end driver integration, so having the FIFO with test values is good enough. In this mode, does the configuration really matters? Shouldn't be enough to initialize the driver, enable the test mode and start the frame generation? Shouldn't that start filling up the FIFO? We have even tried setting the  OSCCLKEN bit to 1 (not sure even if necessary in test mode, but it was worth giving it a try).

Once again, thanks for the help.

0 Likes
frangargiulo
Level 1
Level 1
5 sign-ins First solution authored First reply posted

@Deepa_V we've found a bug in our implementation. While doing the configuration, we were not properly setting the right amount of register values available in the register array, hence probably were overwriting some other values that ended up with this undefined behavior.  The FIFO is now getting filled as expected. Thanks for the fast reply.

0 Likes