AWR2243: MMWL_fileDwld Fail

Hi Vignesh,

Looks like I2C interface is not set properly or SOP setting.

I would request you to look for existing e2e queries on AWR2243 + I2C.

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/989029/awr2243-sop-mode-for-loading-from-spi-then-communicating-via-i2c

Regards,

Jitendra

Hello Jitendra,

I succeeded in firmware download with I2C and the CRC Type set for MasterSS also succeeded.

But I am now facing issue with RF Enable Step.

Error : RADAR/RF subsystem Powerup failed for deviceMap1 with error -8

Any suggestions for this issue?

Thanks and Regards

Vignesh

Hi Vignesh,

If you follow DFP example for I2C 

C:\ti\mmwave_dfp_02_02_03_01\ti\example\mmWaveLink_SingleChip_Example

After FW download (MMWL_firmwareDownload), for AWR2243 ES1.0 sample you need to invoke MMWL_SwapResetAndPowerOn function before invoking MMWL_rfEnable API.

If you are doing the right sequence and still facing issue then please post the trace.txt file generated from your experiment.

Regards,

Jitendra

Hello Jitendra,

My AWR board has the marking 583A. So its a ES1.1 sample I suppose.

Hence I skipped  "MMWL_SwapResetAndPowerOn"  step.

And since I using Jetson AGX Linux host, I could not get a trace.txt file for reference.

How should I proceed in this case?

Thanks and Regards

Vignesh

Hi vignesh,

Did you implement the same code sequence as DFP example?

We need to check how device is reacting with rlDeviceRfStart API (if this API is returning -8)

Check if this API is returning -8 or timoutCnt is causing -8 error

Hello Jitendra,

The code sequence implemented is same as the one in DFP example.

rlDeviceRfStart returns 0.

timoutCnt is causing error -8.

Thanks and Regards

Vignesh

Try to increase the timeout value may be some huge value just for test this.

Regards,

Jitendra

Hello Jitendra,

I tried setting MMWL_API_START_TIMEOUT to 40000.

But that did not work too.

Is this what you also mean?

Thanks and Regards

Vignesh

Hello Jitendra ,

One more observation :

Following is the log during rf Enable :
write to 0x28 ack data: 0x34 0x12 0x21 0x43 0x05 0x80 0x14 0x00 0x03 0x54 0x00 0x00 0x01 0x00 0xE2 0x2B 0x00 0x40 0x04 0x00 0x1F 0x45 0x43 0x2D
write to 0x28 ack data: 0x78 0x56 0x65 0x87 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x28 ack data: 0xBA 0xDC 0xCD 0xAB
read to 0x28 ack data: 0x16 0x80 0x10 0x00 0x0F 0x54 0x00 0x00 0x00 0x00 0xCA 0x2B
read to 0x28 ack data: 0x88 0x23 0xAC 0x5B

Before the last byte 5B is read , Host IRQ is high again. Host interrupt is low for around 16ms.

For other normal operations, Host IRQ is low for around 1sec.

Regards

Vignesh

HI Vignesh,

Does you hostIRQ handler gets called even when HostIRQ is high slightly before read completion of the last response?

Please check that HostIRQ handler (may be GPIO interrupt handler in your Host implementation) is called during above last few bytes capture.

As per above picture response of the RF-power API is returned from the device but async-event is not being read. It is because of HostIRQ is not being registered at Host.

so please check if handler is being called during this scenario.

Hi Jitendra,

Following is the response, 

Meta Image download complete ret = 0

Firmware update successful for deviceMap 1

=====================================================================

I2C Write
3412
2143
8580
200
044
00
10
593b
4c40
100
10
00
00
00
00
00
7b36
1b72
mmn: Wait IRQ Status1
I2C Write
3412
2143
8580
200
344
00
10
563b
4c40
100
10
00
00
00
00
00
3b3b
7adc
mmn: Wait IRQ Status1
mmn: Mask Irq
mmn: Mask Irq: masked
mmn: IRQ handler call
I2C Write
7856
6587
ffff
ffff
ffff
ffff
ffff
ffff
mmn: Wait IRQ Status1
mmn: Wait IRQ Status0
I2C Read
badc
cdab
Sync1 is dcba Sync 2 is abcd I2C Read
9680
100
c44
00
00
4d3b
I2C Read
adc9
4fbb
mmn: Unmask Irq
mmn: Unmask Irq: unmasked
CRC Type set for MasterSS success for deviceMap 1

I2C Write
3412
2143
580
140
054
00
10
e52b
040
40
57a7
d847
mmn: Wait IRQ Status1
I2C Write
3412
2143
580
140
354
00
10
e22b
040
40
1f45
432d
mmn: Wait IRQ Status1
mmn: Mask Irq
mmn: Mask Irq: masked
mmn: IRQ handler call
I2C Write
7856
6587
ffff
ffff
ffff
ffff
ffff
ffff
mmn: Wait IRQ Status1
mmn: Wait IRQ Status0
I2C Read
badc
cdab
Sync1 is dcba Sync 2 is abcd I2C Read
1680
100
f54
00
00
ca2b
I2C Read
8823
ac5b
mmn: Unmask Irq
mmn: Unmask Irq: unmasked
rlDeviceRfStart return value 0
timeOutCnt Counter return value -8
Radar/RF subsystem Power up failed for deviceMap 1 with error -8

The interrup processing is same as for the other steps like MSS Powerup

Regards

Vignesh

Hi Vignesh,

I was asking you to confirm if HostIRQHandler function being called when HostIRQ high during the last few byte reads in the above snapshot.

Try to add some debug print/log in your GPIO interrupt handler (which is connected to HostIRQ) and see if that is calling mmwavelink hostIRQhandler.

And along with that increase the timeOutCnt which wait for rfStart async-event read data.

Regards,

Jitendra

Hello Jitendra,

The above log I shared was with including the suggestions you have made.

1. Host IRQ Handler is not called when the last few bytes are read.

2. I increased the MMWL_API_START_TIMEOUT from 1000 to 2000 and checked. I got the same error. If MMWL_API_START_TIMEOUT   is increased above MMWL_API_INIT_TIMEOUT  , then communication is not working from the very beginning.

Thanks and Regards

Vignesh

Hi Vignesh,

That's the problem, your application should able to raise GPIO interrupt (connected with HostIRQ) as and when HostIRQ is high from the device.

You need to check in your Host application why interrupt handler is not being called when HostIRQ is high even in b/w of data Rd/Wr.

If that interrupt handler will called then Host App can read the async-event msg from AWR device which above while loop is waiting for status.

Regards,

Jitendra

Hello Jitendra,

But before I2C Read, IRQ Mask function is called and only after read IRQ Unmask is called.

So in between how can we call the interrupt handler?

Regards

Vignesh

Hi Vignesh,

Just for this experiment comment the IRQ mask in your callback implementation and see if this works.

Regards,

Jitendra

Hi Jitendra, 

That did not work either.

Regards

Vignesh

I'm out of clue now

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1032451/awr2243-question-about-sop-7-i2c-mode-of-operation

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/989029/awr2243-sop-mode-for-loading-from-spi-then-communicating-via-i2c

I see, this I2C has been ported by the user over E2E.

Hello Jitendra,

So, is it not possible for direct I2C Communication to make it work?

I am confused on how the ASYNC Event for Poweron worked ,and  Firmware download worked with I2C and why this step is not working.

Thanks and Regards

Vignesh

Hello Jitendra,

Thanks for your support.

After changing the Interrupt processing to Edge triggered and including a small delay in the read callback after the read is complete.

It works now.

Once again, thanks for your support.

Regards,

Vignesh