AWR2243BOOST: mmwave Device Power on failed for deviceMap1 with error -8 in AWR Single Chip setup with Jetson AGX

Hi Vignesh,

Did you confirm that HostIRQ line is high when you do nRST toggle under rlDeviceEnable callback?

And make sure that you set the SOP lines correctly before nRST toggle, it should be done after few msec.

Refer AWR2243 datasheet for powerup sequence

https://www.ti.com/lit/ds/symlink/awr2243.pdf  (figure 8-2)

And section 8.9.4 for MibSPI setting.

Hi Jitendra,

The Host IRQ Line is low during nRST Toggle and it goes high after a few milliseconds. SOP Lines are set as (SOP0 - 1 ; SOP1 - 0 ; SOP2 -0 ; 1 is when jumper is connected) . But in the duration between nRST going high and Host Interrupt enable, there is no SPI Message communication happening.

nReset to HostIRQ-high is AWR device boot up time. So during this time there will be no SPI communication.

First HostIRQ line high (post nRESET) is the time when AWR device is ready to have SPI communication.

At this point of time, Host (mmwavelink) will get interrupt and proceed further to communicate with AWR device. If all the callbacks are well connected and implemented then after HostIRQ interrupt all the communication is being handled by mmwavelink library.

Please refer the mmwavlink example from mmWave DFP for application implementation using mmwavelink.

In the RADAR Interface Control document, the above sequence is provided.

As per my understanding , before this communication sequence, there will be the boot up sequence and so HostIrq will go high twice, once after bootup and once after receiving 0x1234 0x4321 message from the host.

Is my understanding correct?

Hi Vignesh,

Let's just focus on SPI communication at the bootup time.

1. As soon as device boots up (post nReset toggle with SOP lines set to functional mode), AWR (SPI slave) will raise HostIRQ line high to notify Host processor that it needs to send some message (power up asynchronous event :SBID: 0x5000)

2. Host Application gets the interrupt (GPIO level or edge trigger) at HostIRQ high, where interrupt handler calls rlDriverHostIrqHandler callback which is being set by rlRegisterInterruptHandler function implementation.

Please refer mmwavelink.h  rlDeviceCtrlCbs_t->rlRegisterInterruptHandler function detail.

And refer this https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/796401/awr1243-mmwave-link-api-interrupt-function-implementation/2951204#2951204

3. At rlDriverHostIrqHandler invocation, mmwavelink will spawn a thread by calling rlOsiSpawn callback. This thread should call mmwavelink rlDriverMsgReadSpawnCtx function which is now responsible take next action.

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/915603/awr1243boost-port-mmwavelink-to-linux

4. to response to HostIRQ High, mmWavelink writes the CNYS pattern (0x5678 0x8765... [16byte]) over SPI to AWR device.

5. AWR reads this CNYS pattern and if parse it correctly, it copies async-event or response message to SPI buffer/FIFO and then takes HostIRQ down.

6. Host Application (mmwavelink), after writing the CNYS pattern wait for HostIRQ to go down, by calling rlDeviceWaitIrqStatus callback. Application needs to implement this rlDeviceWaitIrqStatus callback where it checks in loop for GPIO to go low ( but for a limited loops to avoid infinite iteration) and then returns 0 (success) or -1 (error).

Refer mmwavelink.h rlDeviceCtrlCbs_t-> rlDeviceWaitIrqStatus

7. as soon as HostIRQ status is low from above call, it goes ahead and reads the message from AWR device over SPI and then parse it.

8. Based on Header flag of read message, if it is asynchronous event message then it calls rlAsyncEvent callback function which is being implemented in the application to set the required flag or process the payload data. 

9. At this point Host Application has read the PowerOn async-event message and set the mmwl_bInitComp flag (as per mmwave DFP example) for initial boot up status done.

retVal = rlDevicePowerOn(deviceMap, clientCtx);
while (mmwl_bInitComp == 0U)
{ ....}

could you confirm if you are able to get till this points??

10. If this path is done then further command and response flow should work without any problem.

Note: AWR device can raise HostIRQ only once (one at a time) till processing of that is being done by the Host application (in terms of read the requested data from AWR device.

Please use and refer mmWave DFP & its example

https://www.ti.com/tool/download/MMWAVE-DFP-2G/02.02.03.01

Let me know if you need any other assistance or support.

Regards,

Jitendra

Hello Jitendra,

Host Irq is high even before nRESET toggle is happening and the following behaviour is observed using logic analyser. Could you please guide, where could be the issue?

Regards

Vignesh

Hi Vignesh,

HostIRQ might be high if it gets powered up.

In your design either you need to set nReset low and bring it high when you need to power on the AWR device. 

or do the toggle during rlDevicePowerOn API call to reset the device and get the HostIRQ interrupt routed to your GPIO interrupt handler to further process the SPI data for Async-event message.

From the above logic analyzer snapshot: are you able to get the SPI communication working. I can't interpret the SPI data there.

Let's focus around first HostIRQ just after the nReset and see the SPI data (rx/tx). And check the mmwavelink flow as well when HostIRQ high (GPIO interrupt).

Hello Jitendra, I am following the flow of mmwavelink with the steps you provided and I reach up to step 5 where my host device sends the CNYS pattern over SPI but HOSTIRQ is never brought down. Here is a screen grab of my signals during this sequence: 

And here is a close up of the SPI data:

Looks like your bytes are swapped here. I'm attaching one of working SPI log with AWR2243 device for your reference.

Hi Jitendra, I am unsure why exactly my bytes are swapped. I have verified that my SPI sends data not swapped using a dummy buffer. However when running my application the bytes are swapped as they are in my previous picture.

Please check if your system (FPGA) is little or big endian. AWR is little endian system.

mmWaveLink supports both of endianess system where you need to recompile the library with MMWL_BIG_ENDIAN MACRO.

Thank you for the quick replies, my system is on the Raspberry Pi and I have confirmed it is little endian. I will continue to look into why my spi bytes are swapped while executing with mmwavelink.

Closing this thread, as new thread started on this topic

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1040740/awr2243boost-spi-communication-and-rldriverrecievesync-error