• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Answers 4 answers
  • Subscribers 30 subscribers
  • Views 2209 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AWR1243: SPI Command Timeout

Antonio Puglielli
Expert 1025 points
Part Number: AWR1243

Hello,

I am controlling the AWR1243 over SPI using an FPGA as a host. We are programming it by issuing commands according to the app note discussed on page ccxxxiii of the AWR1XX_Radar_Interface_Control document (v 0.95). The first few commands are successful, however after a certain point we receive either timeouts or errors and cannot understand what is happening. Please see the following experiments, where steps refers to the steps outlined in the document above:

Steps                                 Result
1,2,3,4,8,9                         Error 35 after 9g
1,2,3,4,5,8,9                      Error 35 after 9g
1,2,3,4,5,6,8,9                   Error 35 after 9g
1,2,3,4,5,6,7,8,9                Timeout after 7c
1,2,3,4,5,7,8,9                   Error 1022 after 7f
1,2,3,4,6,7,8,9                   Timeout after 7d
1,2,3,4,6,8,9                      Error 35 after 9g
1,2,3,4,7,8,9                      Error 1022 after 7f

Note that:

- If we issue all the APIs in the proper order (experiment 4), the radar stops responding after step 7c (AWR_DEV_RX_DATA_PATH_LANE_EN_SB). We have verified on the scope that the proper message is being sent with correct CRC.

- If we skip some commands, then step 7c succeeds but eventually we receive error messages. 

- The error messages do not make sense. Error 35 does not relate to command 9g (AWR_CALIB_MON_TIME_UNIT_CONF_SB). We have checked Error 1022 against our data and find that our data is correct (clock position is 3). 

Can you please advise as to what would cause the radar to stop responding to SPI messages? 

Thanks for your assistance.

Best,

Antonio

  • 0
    TI__Genius 15005 points
    Antonio,

    Error 35 seems to indicate incorrect profile config. Could you please provide the values you send on the bus for 9d, 9e and 9f?

    Thanks,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points
    Hi Anand,

    Here is how we are configuring the radar.

    9d (AWR_PROFILE_CONF_SET_SB):

    profile_index = 0x0000
    pf_vco_select = 0x02
    pf_callut_update = 0x01
    pf_freq_start = 0x558e38e4 (77GHz)
    pf_idle_time = 0x000003e8 (10us)
    pf_adc_start_time = 0x0000023a (5.7us)
    pf_ramp_end_time = 0x00001964 (65us)
    pf_tx_out_power_backoff = 0x00000000 (0dB)
    pf_tx_phase_shifter = 0x00000000 (0 degrees)
    pf_freq_slope_const = 0x04db (60 MHz/us)
    pf_tx_start_time = 0x0064 (1us)
    pf_num_adc_samples = 0x0400 (1024)
    pf_dig_out_sample_rate = 0x493e (18.75MSps)
    pf_hpf_corner_1 = 0x00
    pf_hpf_corner_2 = 0x00
    reserved = 0x0000
    pf_rx_gain = 0x1e (30dB)
    reserved = 0x0000


    9e (AWR_CHIRP_CONF_SET_SB):

    chirp_start_index = 0x00
    chirp_end_index = 0x00
    profile_index = 0x00
    reserved = 0x0000
    chirp_start_freq = 0x00
    chirp_freq_slope = 0x00
    chirp_idle_time = 0x00
    chirp_adc_start_time = 0x00
    chirp_tx_en = 0x00


    9f (AWR_FRAME_CONF_SET_SB):

    reserved = 0x0000
    chirp_start_idx = 0x00
    chirp_end_idx = 0x00
    num_loops = 0x01
    num_frames = 0x05
    reserved = 0x0000
    frame_periodicity = 0xf4240
    trigger_select = 0x0001 (SW_TRIGGER)
    reserved = 0x0000
    frame_trigger_delay = 0x0000


    Best,
    Antonio
  • 0 in reply to Antonio Puglielli
    Expert 1025 points
    FYI we have also tried the following changes:

    pf_callut_update = 0x00 (AWR_PROFILE_CONF_SET_SB)
    chirp_tx_en = 0x01 (AWR_CHIRP_CONF_SET_SB)

    But there is no change in behavior. We still get error 35 after step 9g (AWR_CALIB_MON_TIME_UNIT_CONF_SB).
  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points
    Hi Antonio,

    Would you be able to get the actual SPI messages that are going out on the bus when you call these APIs? I'm specifically looking for the one in step 9d, but it's even better if you can get all the messages from the beginning.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points

    Hi Anand,

    Here is the message 9d (all hex obviously):

    4321 1234 0201 003e

    e000 0000 0001 1dbf

    0100 0030 0000 0102

    558e 38e4 0000 03e8

    0000 023a 0000 1964

    0000 0000 0000 0000

    04db 0064 0400 493e

    0000 0000 001e 0000

    2736

    We are working on getting you the other messages but any feedback in the meantime would be useful.

    Best,

    Antonio

  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points
    Hi Antonio,

    Are you using a big-endian processor by any chance?

    It appears that some of these fields are incorrectly populated. I see the 0x4321-0x1234 words are swapped, and more importantly the 4-byte fields of the message like PF_FREQ_START_CONST also having its most-significant word first.

    Could you fix this and try again?

    Below is an example message to configure profile config with the corresponding decoding for reference:
    0x1234 0x4321 0x0201 0x003E
    0x6000 0x0000 0x0001 0x9DBF
    0x0100 0x0030 0x0000 0x0000
    0x8300 0x5478 0x06A2 0x0000
    0x0258 0x0000 0x1A30 0x0000
    0x0000 0x0000 0x0000 0x0000
    0x0122 0x0064 0x0800 0x83D6
    0x0002 0x0000 0x0030 0x0000
    0xFB11

    The corresponding field decoding is:
    PF_INDX = 0x00
    "PF_VCO_SELECT = 0x00
    PF_CALLUT_UPDATE = 0x00"
    PF_FREQ_START_CONST Start Frequency = 76.024 GHz
    PF_FREQ_START_CONST
    PF_IDLE_TIME_CONST 16.98 us
    PF_IDLE_TIME_CONST
    PF_ADC_START_TIME_CONST 6 us
    PF_ADC_START_TIME_CONST
    PF_RAMP_END_TIME 67.04 us
    PF_RAMP_END_TIME
    PF_TX_OUTPUT_POWER_BACKOFF
    PF_TX_OUTPUT_POWER_BACKOFF
    PF_TX_PHASE_SHIFTER
    PF_TX_PHASE_SHIFTER
    PF_FREQ_SLOPE_CONST 14 MHz / us
    PF_TX_START_TIME 1 us
    PF_NUM_ADC_SAMPLES 2048 samples
    PF_DIGITAL_OUTPUT_SAMPLING_RATE 33750 ksps
    "PF_HPF1_CORNER_FREQ
    PF_HPF2_CORNER_FREQ" "350 kHz
    350 kHz"
    RESERVED
    PF_RX_GAIN 48 dB

    Hope this helps.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points

    Thanks, Anand for the suggestion. We will try this tomorrow in the lab.

    We are using an FPGA as host processor (so we control the endianness) and had a very difficult time understanding the endianness that the SPI module expects on the AWR1243. Unfortunately we found the documentation quite confusing and previous questions posted on the forum were not answered in a clear way. I am grateful that you are addressing our question in a clear and helpful way!

    To help us correctly implement our host, can you explain the endianness rules that the AWR device expects? One confusion I have after your answer is you state that the SYNC words are swapped, yet the radar sends an ACK after we send this message. This implies to me that it is legally formatted (even if the message values are inconsistent). How do I resolve my confusion? 

    If you can describe the endianness rules at the chip pin, we can engineer our host properly to respect those rules. 

    Thanks!

    Antonio

  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points

    Hi Antonio,

    The AWR1243 expects all fields in the message headers and message data that are larger than one byte are sent out in little-endian byte order. This is mentioned in section 2.3 of the AWR1xxx Radar Interface Control document.

    I did notice the inconsistency with the swapped SYNC words and I'm following up internally to see why this message was ACKed. It should have resulted in an ERROR response no response.


    By the way, since you appear to be bringing up a new design on your own, it might help to have an AWR1243 EVM for reference. RadarStudio/mmWaveStudio allows you to control the EVM from a host PC and send and there is a trace.txt file it generates which can be read to inspect any SPI data that is sent or received between the PC and the AWR1243.

    Best Regards,
    Anand

  • 0 in reply to Anand Gadiyar
    TI__Genius 15005 points
    Hi Antonio,

    We are not able to replicate this at TI. An ACK is sent only if the message is properly formatted and has no errors. If the SYNC words do not match, the AWR1243 will ignore the message and should generate no response (and no error).

    It would be useful if we could see the SPI bus traffic to make sure that there is really an ACK.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points

    Hi Anand,

    It turns out that we mis-communicated the SYNC sequence, we are actually sending 0x1234 4321. So no problem there.

    Procedure

    We have modified our host to send commands with the proper endianness. Here is the sequence of commands that we send:

    • (3) AWR_DEV_RFPOWERUP_SB:                                                      0x1234 4321 8005 0012 0000 0000 0001 7fe7 4000 0004 8b67
    • (5a) AWR_RF_LDO_BYPASS_SB:                                                      0x1234 4321 0581 0016 1000 0000 0001 ea67 02cc 0008 0000 0001 3b80
    • (6a) AWR_CHAN_CONF_SET_SB:                                                     0x1234 4321 0101 001a 2000 0000 0001 dee3 0080 000c 000f 0007 0000 0000 004d
    • (6b) AWR_ADCOUT_CONF_SET_SB:                                                0x1234 4321 0101 001a 3000 0000 0001 cee3 0082 000c 0002 0001 0000 0000 fbcb
    • (6c) AWR_LOWPOWERMODE_CONF_SET_SB:                               0x1234 4321 0101 0016 4000 0000 0001 bee7 0083 0008 0000 0000 75db
    • (6d) AWR_DYNAMICPOWERSAVE_CONF_SET_SB:                        0x1234 4321 0101 0016 5000 0000 0001 aee7 0084 0008 0000 0000 afb7
    • (7a) AWR_DEV_RX_DATA_FORMAT_CONF_SET_SB:                     0x1234 4321 8085 001e 6000 0000 0001 1f5b 4041 0010 000f 0002 0001 0000 0000 0000 38bd 
    • (7b) AWR_DEV_RX_DATA_PATH_CONF_SET_SB:                           0x1234 4321 8085 001a 7000 0000 0001 0f5f 4042 000c 3600 0200 2020 0020 701f
    • (7c) AWR_DEV_RX_DATA_PATH_LANE_EN_SB:                              0x1234 4321 8085 0016 8000 0000 0001 ff63 4043 0008 000f 0000 0489
    • (7d) AWR_DEV_RX_DATA_PATH_CLK_SET_SB:                              0x1234 4321 8085 0016 9000 0000 0001 ef63 4044 0008 0101 0000 4b8f
    • (7e) AWR_HIGHSPEEDINTFCLK_CONF_SET_SB:                           0x1234 4321 0101 0016 a000 0000 0001 5ee7 0085 0008 000a 0000 3923
    • (7f) AWR_DEV_CSI2_CFG_SET_SB:                                                 0x1234 4321 8085 001a b000 0000 0001 cf5f 4047 000c 5421 0003 0000 0000 103c
    • (8)   AWR_RFINIT_SB:                                                                         0x1234 4321 0181 0012 c000 0000 0001 3e6b 00c0 0004 fea6
    • (9d) AWR_PROFILE_CONF_SET_SB:                                               0x1234 4321 0201 003e e000 0000 0001 1dbf 0100 0030 0000 0102 558e 38e4 0000 03e8 0000 023a 0000 1964 0000 0000 0000 0000 04db 0064 0400 493e 0000 0000 001e 0000 2736

    Results

    We observe the following behavior:

    Case 1: If we follow the above sequence exactly, we get ACKs until message 7c, where we get a timeout / no response.

    Case 2: If we follow the above sequence but skip message 7c, we get a timeout / no response on message 7d

    Case 3: If we skip messages 7c and 7d, we get a timeout / no response at message 7f.

    Case 4: If we skip messages 7a-f, we get an error code 35 (profile index > 4) on message 9d. 

    Are you able to replicate this behavior or identify any issues in our procedure or message formats? Thanks very much for your assistance. 

    Best,

    Antonio

  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points
    Hi Antonio,

    These settings look okay to me, but I will take a closer look again.

    Meanwhile, would you be able to capture the responses from the device for each of these commands?

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points

    Hi Anand,

    Here are the responses we observe:

    • AWR_DEV_RFPOWERUP_SB:                                      0xDCBA ABCD 8016 000E 000C 0000 0000 7FCF 906C
    • AWR_RF_LDO_BYPASS_SB:                                        0xDCBA ABCD 0592 000E 1000 0000 0000 EA5F DA86
    • AWR_CHAN_CONF_SET_SB:                                       0xDCBA ABCD 0112 000E 2000 0000 0000 DEDF 16A2
    • AWR_ADCOUT_CONF_SET_SB:                                 0xDCBA ABCD 0112 000E 3000 0000 0000 CEDF 30E8
    • AWR_LOWPOWERMODE_CONF_SET_SB:               0xDCBA ABCD 0112 000E 4000 0000 0000 BEDF CA1E
    • AWR_DYNAMICPOWERSAVE_CONF_SET_SB:        0xDCBA ABCD 0112 000E 5000 0000 0000 AEDF EF54
    • AWR_DEV_RX_DATA_FORMAT_CONF_SET_SB:   0xDCBA ABCD 8096 000E 600C 0000 0000 1F4F FEE9
    • AWR_DEV_RX_DATA_PATH_CONF_SET_SB:          0xDCBA ABCD 8096 000E 700C 0000 0000 0F4F DBA3
    • AWR_DEV_RX_DATA_PATH_LANE_EN_SB:               no response received

     


    As far as I can tell, these are all the expected responses. After AWR_DEV_RX_DATA_PATH_LANE_EN_SB, the device becomes unresponsive. 

    Best,

    Antonio

  • 0 in reply to Antonio Puglielli
    Expert 1025 points

    Hi Anand,

    Any feedback for us? Are you guys able to replicate this behavior, or have any ideas what may cause something like this?

    Best,

    Antonio

  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points
    Hi Antonio,

    We are not able to replicate this behavior even with the exact sequence you used. We reviewed the SPI commands and there is nothing wrong there

    If possible, could you please try the following experiment:
    1) In the last sequence you gave, can you repeat the AWR_DEV_RX_DATA_PATH_CONF_SET_SB command several times? This was the last working command before the no-response.
    1a) If this fails, then in a new test repeat the previous command (AWR_DEV_RX_DATA_FORMAT_CONF_SET_SB) several times. Else,
    1b) If (1) goes through successfully, then issue the AWR_DEV_RX_DATA_PATH_LANE_EN_SB command. If you still get a no-response, issue the AWR_DEV_RX_DATA_FORMAT_CONF_SET_SB command again.

    In each reissued command, make sure the sequence number and CRC/Checksums are updated.

    We are mainly looking to see if this helps isolate the behavior a little better.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points

    Hi Anand,

    We tried several tests based on your suggestions. 

    6d = AWR_DYNAMICPOWERSAVE_CONF_SET_SB

    7a = AWR_DEV_RX_DATA_FORMAT_CONF_SET_SB

    7b = AWR_DEV_RX_DATA_PATH_CONF_SET_SB 

    Here is what we tried:

    1) ... 7a - 7b - 7b. (Your suggestion #1) We get a timeout at this point. 

    2) ... 7a - 7a - 7a. (Your suggestion #1a) We get a timeout at this point.

    3) ... 6d (12x) - 7a. We can repeat 6d (or any other of the 6 family of commands) arbitrary number of times. We timeout the first time we enter the 7 commands. 

    We have verified that the sequence number increments properly when repeating the commands, and the CHECKSUM matches that correctly. For example, in test number 3, command 7a is sent as:

    0x1234 4321 8085 001e f000 0000 0001 8f5b 4041 0010 000f 0002 0001 0000 0000 0000 7553.

    Best,

    Antonio

  • 0 in reply to Antonio Puglielli
    Expert 1025 points

    Hi Anand,

    I have tried a number of new things and I have found some interesting behavior that may offer some clues as to what the problem may be.

    New Board

    I flashed a new AWR1243BOOST with DFP 1.0 and repeated the tests above - the same behavior was observed. 

    Variable command Repetition

    I experimented with repeating commands various times. There is a specific pattern that causes failures. For these results, I repeat AWR_ADCOUT_CONF_SET_SB 12 times, and I repeat AWR_LOWPOWERMODE_CONF_SET_SB a variable number of times. 

    • 1x AWR_LOWPOWERMODE_CONF_SET_SB: No timeout
    • 2x AWR_LOWPOWERMODE_CONF_SET_SB: No timeout
    • 3x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_CSI2_CFG_SET_SB (step 7f)
    • 4x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_CSI2_CFG_SET_SB (step 7f)
    • 5x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_RX_DATA_PATH_CLK_SET_SB (7d) 
    • 6x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_RX_DATA_PATH_LANE_EN_SB (7c)
    • 7x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_RX_DATA_PATH_CONF_SET_SB (7b)
    • 8x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_RX_DATA_FORMAT_CONF_SET_SB (7a)
    • 9x AWR_LOWPOWERMODE_CONF_SET_SB: Same
    • 10x AWR_LOWPOWERMODE_CONF_SET_SB: Same
    • 11x AWR_LOWPOWERMODE_CONF_SET_SB: Same
    • 12x AWR_LOWPOWERMODE_CONF_SET_SB: Same
    • 13x AWR_LOWPOWERMODE_CONF_SET_SB: Same
    • 14x AWR_LOWPOWERMODE_CONF_SET_SB: Same
    • 15x AWR_LOWPOWERMODE_CONF_SET_SB: Same
    • 16x AWR_LOWPOWERMODE_CONF_SET_SB: No timeout
    • 17x AWR_LOWPOWERMODE_CONF_SET_SB: No timeout
    • 18x AWR_LOWPOWERMODE_CONF_SET_SB: No timeout
    • 19x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_CSI2_CFG_SET_SB (step 7f)
    • 20x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_CSI2_CFG_SET_SB (step 7f)
    • 21x AWR_LOWPOWERMODE_CONF_SET_SB: Timeout after AWR_DEV_RX_DATA_PATH_CLK_SET_SB (7d) 

    Notice in particular that:

    • There is no timeout under certain specific conditions
    • The timeout behavior is periodic with period 16
    • The timeout behavior skips AWR_HIGHSPEEDINTFCLK_CONF_SET_SB (7e). Based on the pattern we would expect it to timeout on 7e during the 20x and 4x tests above, but it does not.

    Based on this I think that there is some bad interaction between the SEQNUM field and the MSGID 0x8085 which is common for steps 7a, 7b, 7c, 7d, 7f. This may result in a bad checksum which causes the no response / timeout. With this hypothesis, for special values of the SEQNUM field, there is no such collision - that is why the behavior succeeds for some repetitions. 

    Any thoughts based on these results?

    Best,

    Antonio

  • 0 in reply to Antonio Puglielli
    Expert 1025 points
    Hi Anand,

    We figured out that we were computing the checksum incorrectly - we had inadvertently used a twos complement instead of ones complement addition. Having fixed that, the timeout issue is now gone.

    Now, we always get error 35 when we send command AWR_PROFILE_CONF_SET_SB (9d). As we verified above, we are setting the proper profile index = 0, so i am confused why we get this error. Note that we do NOT send message AWR_LOOPBACK_BURST_CONF_SET_SB (9c). Could this be the reason for this error?

    Best,
    Antonio
  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points
    Hi Antonio,

    I guess I missed the checksum computation. I will review your SPI messages again. Could you please post your updated SPI commands here?

    The AWR_LOOPBACK_BURST_CONF_SET_SB is optional - you would not normally need to call it.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Genius 15005 points
    Hi Antonio,

    I think you again have an issue with the 4-byte fields in the profile config message.

    For example, the PF_FREQ_START_CONST data should be 0x558e followed by 0x38e4, whereas you are currently swapping these two words.

    Please send me an updated sequence and I can review it again.

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Expert 1025 points
    Hi Anand,

    We managed to figure out and solve our issues. There were some small implementation bugs that did not handle the fields properly.

    Thanks very much for your help. Your suggestions were very useful and helped us find several issues in our implementation.

    Best,
    Antonio
  • 0 in reply to Antonio Puglielli
    TI__Genius 15005 points
    Hi Antonio,

    You're always welcome!

    I'm glad you managed to figure this out.

    I would recommend having a TI EVM along for reference when you're bringing up your own setup for the first time.

    Best Regards,
    Anand