AWR1243BOOST: Problem in sending ADC data over SPI

Dear Anand,

While you're checking whether this feature is supported and how it works, I've noticed a couple of things that might be of interest.

1. SOP mode configuration.
   In controlling AWR1243BOOST from an external processor, my expetation was that SOP mode must be connfigured to functional mode (i.e., 001 - SOP0 jumper closed and the others open).
   However, we noticed that there no way to control the AWR1243BOOST from an external processor through SPI unless we set the SOP mode exactly to the dual of the functional mode (i.e., 110 - SOP1 and SOP2 jumpers closed and SOP0 open).
2. To send ADC data via SPI we set a very short frame (up to three pulses) with a frame repetition time of 1 second. This was intented to support the required ADC rate through the low throughput of the SPI lines. However in this case we don't see any SPI packet with ADC data. In contrary, if I set a long frame (which in principle would not be supported by the SPI throughput) I can see the first async event with ADC bytes as described in my first post.
3. After sendind the rlSensorStart command, the AWR1243 protocol foresees an ack to be sent from the device to the external processor. This ack, sent via an async event (over SPI) is correctly received. But I have a doubt: might it be that in the meanwhile the ADC buffer is ready to send data over SPI, it try access the SPI bus which instead is already busy for the ack to the rlSensorStart? This could explain why I do not receive any ADC packet with short frames (it senses the bus which is busy and stops) while I receive the first data packet with long frames (the first is received beacuse while the frame is forming, the ack to the rlSensorStart has been sent and the bus is let unloaded). Plus, in the latter case I receive just the first data packet beacuse the SPI rate is not suffient to support the ADC required throughput.

To try to overcome the problem at point 3. we tried to use an external trigger: So we wait the ack to the rlSensorStart (which is immediate for human beings clocking...) and then we start the transmission. However, also in this case we didin't succed. So somethings is still missing.

Hope you're finding a solution.

Regards,

Paolo.

Hi Jitendra,

Thanks for your reply.

I didn't understand what "Si version" actually means and where to retrieve this information.

However, I got this answer from the chip after poweron the device.

RF Version [ 2. 0. 0.15]
MSS version [ 1.10. 0.23]
mmWaveLink version [ 1. 0. 0. 0]

Thanks,

Paolo.

Hi Jitendra,

For the boards I've tested up to now, the content of "Die id" field is: Lot:6000001/Wafer:1/DevX:30/DevY:18.

We have also a second set of boards, whose "Die id" is: Lot:7120004/Wafer:5/DevX:4/DevY:59.

Can you please explain me the difference among them (if any) and clarify whether I need to take some further actions in using the AWR1243 device from an external host? (e.g., dfp version, mss and bss version, etc.)

Thank you in advance,

Paolo.

About Silicon version, it is ES2.0 in both cases.

Hi Paolo,

I have tried mmWave_example of DFP 1.0.0.1  on AWR1243 ES2.0 where I ran pre-built .exe but the change in mmwaveconfig.txt

intfSel=2; /* For ADC over SPI */

chirpEndIdxFCF=2; /* reduce no. of chirp to total 3 in a frame */

frameCount=1; /* single frame */

And I see multiple Async event for ADC data over SPI (in trace.txt, subID 0x500A, search for '[RD]0x500A' text in this file)

Could you please try above setting change (mmwaveconfig.txt: single frame setting) with existing exe application at your end.

Note- Based on single frame you can find out how much time device takes (time difference in trace.txt from first Async event to last one) to send all async event and give that much frame duration for muli-frame setting.

Regards,

Jitendra