AWR1243: WARM_RESET PIN changes state

Hi,

It will take use a few days to get back to you

thank you
cesar

Hi Sakamoto-san,

The WARM_RESET pin, specifically on the AWR1243 and AWR1243P devices, is actually a reset status output pin. This is programmed by the DFP firmware and not a behavior that can be modified by the user. 

This pin should only toggle when the NRESET pin state changes during power on/off cycles.

Are you seeing any problems using these devices when the WARM_RESET pin toggles?

Thank you,

-Randy

Hello Randy-san, Cesar-san

Thank you for your reply.

> Are you seeing any problems using these devices when the WARM_RESET pin toggles?

Yes.
Before or after the WARM_RESET pin toggles, my external host is receiving garbage data from the CSI2 lane.
At this time, the NRESET pin state remains on.
Since this phenomenon occurs during running frames, there is a problem that correct data cannot be received.
I want to work around this problem.

Thank you,

Sakamoto

Hi Sakamoto, 

Is this a custom designed AWR1243P RF and host processor system you are experimenting with?

Do all of the AWR1243P devices power cycle, reset and configure correctly? Do you observe the WARM_RESET toggles only while chirping is active? 

Thank you,

-Randy

Hello Randy-san,

Thank you for your reply.

>Is this a custom designed AWR1243P RF and host processor system you are experimenting with?
Yes.
These are not MMWCAS-RF-EVM and MMWCAS-DSP-EVM, but our own experimental machines.

>Do all of the AWR1243P devices power cycle, reset and configure correctly?
Yes.
The SOP pins and nRESET pins are controlled by the external host, and the power of four AWR1243P devices can be configured.

>Do you observe the WARM_RESET toggles only while chirping is active?
No.
I observed that the WARM_RESET toggles not only while chirping is active (ie after the function : rlSensorStart).
The flow until my AWR1243Ps run chirp is as follows.
 1. The DC Power On
 2. The SOP Pins On
 3. The nReset Pins On (using rlDevicePowerOn or rlDeviceAddDevices)
 4. The chip configuration by functions of mmWaveLink
 5. Executing rlSensorStart
 6. The external host sends a pulse to the SYNC_IN pins on AWR1243Ps continuously
I observed the WARM_RESET toggles on any of the above 2 ~ 6.
The toggle frequency is especially high between 6.

Thank you,

Sakamoto

Hi Sakamoto, 

In your startup flow, can you please verify some other details for me? I was not sure if you were simplifying the flow or missing some steps. 

The startup flow should be: 

1. Power enable

2. NRST driven low

3. Power good on all rails verified 

4. SOP mode pins set

5. NRST driven high (this latches in the SOP mode for the boot loader mode select

6. SPI (or QSPI) firmware loading

7. Device configuration over SPI API commands

The rlDevicePowerOn or rlDeviceAddDevices do not toggle the NRST state. These are API commands which wills startup the BSS  processor subsystem. 

Are you referencing the AWRx ICD document? http://downloads.ti.com/ra-processors/esd/MMWAVE-DFP/latest/exports/mmWave-Radar-Interface-Control.pdf. The "Reset Release" referred to in "3.2.3 Flow Diagram (Host) – Bootup/ Asynchronous Event" is not equivalent to the NRST hardware pin toggle necessary during startup. 

Please verify that NRST and SOP pins are being setup as I have outlined above. 

Thank you,

-Randy

Hello Randy-san,

Thank you for your reply.

Sorry, I simplified the previous flow.
The details of the startup flow of my system are as follows.

1. Power enable

2. NRESET driven low
   (My system sets the NRESET pins on 4 chips to the low state at the same time.)

3. Power good on all rails verified

4. SOP mode pins set
   (My system sets the SOP pins on 4 chips to 0,0,1 (functional mode) at the same time.)

5. The master chip setting
  5.1. The external host excutes "rlDevicePowerOn"
        Then, the callback function "rlDeviceEnable" is called from "rlDevicePowerOn", and rlDeviceEnable sets NRESET on the master chip to High.

  5.2. Waiting for RL_DEV_AE_MSSPOWERUPDONE_SB from the master chip

  5.3. SPI firmware loading for the master chip

  5.4. The external host excutes "rlDeviceSetMiscConfig" and "rlDeviceRfStart" for the master chip

  5.5. Waiting for RL_DEV_AE_RFPOWERUPDONE_SB from the master chip

6. The slave chips setting (Executing the following for all slave chips)
  6.1. The external host excutes "rlDeviceAddDevices"
        Then, the callback function "rlDeviceEnable" is called from "rlDeviceAddDevices", and rlDeviceEnable sets NRESET on the slave chip to High.

  6.2. Waiting for RL_DEV_AE_MSSPOWERUPDONE_SB from the slave chip

  6.3. SPI firmware loading for the slave chip

  6.4. The external host excutes "rlDeviceSetMiscConfig" and "rlDeviceRfStart" for the slave chip

  6.5. Waiting for RL_DEV_AE_RFPOWERUPDONE_SB from the slave chip

7. Device configuration over SPI API commands

>The rlDevicePowerOn or rlDeviceAddDevices do not toggle the NRST state. These are API commands which wills startup the BSS  processor subsystem.

Please tell me more information about this.
rlDevicePowerOn and rlDeviceAddDevices call the callback function "rlDeviceEnable". The following is described in the comment of this callback function.

'Bring mmWave radar device out of Reset. Implement this function to assert the nReset Pin in mmWave device. Optionally It might require to assert Sense on Power(SOP) Pins'

Therefore, I think that by registering a function to toggle the NRESET pin to high in rlDeviceEnable, rlDevicePowerOn or rlDeviceAddDevices toggle the NRESET state.

Is this my idea wrong?
What processing should be registered in the callback function for rlDeviceEnable?

Thank you,

Sakamoto

Hi Sakamoto, 

Were you able to follow-up on my additional questions?

Thank you,

-Randy