AWR1243: MIPI error reported when connected to third-party board

Hello Andrea,

As there are errors not from the AWR1243, there is not we can debug. These have to be respected from the Nvidea side. I would suggest to check with Nvidea as we cannot debug their platform issues.

Regards,
Saswat Kumar

Hi Saswat and thanks for your interest.

I am trying to debug Nvidia's side, but it seems that a misconfiguration between Awr and Jetson is happening.

I am assuming right now, based on the documentation that one frame on CSI in normal operating conditions, would be:

(1024 samples I + 1024 samples Q +2 channel_metadata samples) *N_channels + 6 metadata samples

In a case of 4 channels, this would be a 8206 (w) x 1 (h) frame.

Is this a correct assumption?

Best,

Andrea

Hello Ansrea,

Can you give me which exact document you are referring to for this calculation? and how you came to the conclusion?

Regards,
Saswat Kumar

Hi Saswat,

from AWR1243 Transceiver datasheet, in 9.4.1 ADC Data Format over CSI2 interface, there is this diagram:

From here, I figured the formula based on number of samples and number of active channel.

Going deeper in the documentation I found that height=#chirps, while width is computed based on the formula (...right?)

I am using the mmwave example code as reference.

Thanks!

Kind regards,

Andrea

Hello Andrea,

Can you confirm in your script is the DATA_TRANS_FMT_PACKET0 set to ADC only?
are the CQ packet also 0 then?

Then in that case you dont need to consider the rest of the packets which will not be generated.

Also 

CSI frame width (in bits) : samples per chirp*number of RX*2 (if complex) or 1 (if real))*number of bits per sample

The number of Tx chosen doesn't affect the Rx path and amount of data sent out. Also on the CSI2 lanes, as per the MIPI spec, the data is sent as 8 bit (1 byte) data distributed on the lanes. Hence, the long packet header data will contain the CSI frame width in terms of bytes of transfer.

CSI frame height: number of chirps per frame (as you noted)

Regards,
saswat Kumar

Hi Saswat,

thanks for your response.

We did our tests as follows:

- setup the pattern generation:

A) 64samples*4(RXchannels) *2(complex)

B) 16 bits of pattern data

C) 2 MIPI CSI lanes

D) clock: 150 MHz DDR -> 1 bit = 3.333 ns

On the oscilloscope we see 13654ns worth of data -> expected from: 64*4*2(A)*3.333(D)*16(B)/2(C)=13651ns -> this is OK.

- On the device tree side we have:

a) active_w = 512  (->A)

b) pixel_clk_hz = 37500000 (150M*2 (DDR) * 2(CSI LANES) / 16 = 37.5M)

c) csi_pixel_bit_depth = 16

d) mode_type=yuv pixel_phase=yuyv (just picked a format with 16 bits)

e) num_lanes = 2

Still we are having errors on Jetson CSI's driver ( in particular, same as above but different error numbers when the frame is triggered and when it is not triggered.

Do you have any suggestion on what to tweak?

Also, when you say MIPI outputs as byte multpiles, do you mean that a single 12 bit packets (for example) has to become 16 or that at the ond of the train of packets it will be rounded to the nearest byte?

Thanks a lot,

Andrea

Hi Saswat.

Sorry to bother, do you have any advice on that?

Thanks

Andrea

Hi Saswat,

follow-up questions, regarding the datasheet posted above:

- when only 1 channel is enabled, do I still get 4 headers?

Thanks.

Hello Andrea,

Sorry I was out of office, let me review and get back.

Regards,
Saswat Kumar

Hello Andrea,

Can you confirm if the operating clock between the 2 devices are matching?
Let me check on the header part of it.

Regards,
Saswat Kumar

Hi Saswat, sorry for not keeping you up.

It seems like I finally solved the mismatching time problems and got the two communicating.

Now I am receiving frames through v4l2-ctl, the drivers seems to be working.

The problem at this point is, all I receive is 0.

I think it could be because my kernel expects a 16 bit yuv422 format while it should be a raw16 format.

But maybe something else is happening, does anything come to your mind?

By the way, we achieved this communication by setting AdcSamples=510 and expecting 512 samples on the other side (so header =2?)

Hello Andrea,

for this we actually have a CSI2 receiver which captures the data for any transmitter.
Based on that we verify whether you are getting valid data.
Can you please check whether you are getting full data whether there are 2 header packets?

Regards,
Saswat Kumar

Hi Saswat,

unfortunately I cannot afford that device, so I have to think on how to debug without it.

The header issue though, should be a spec-related issue, and someone from TI should be able to respond to that.

Best regards,

Andrea

Hello Andrea,

From what I understood with my design team, the part you are referring to as headers, will be there regardless of the channels enabled.

Regards,
Saswat Kumar