• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 1188 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AWR1243: DFP mmwl_powerOnMaster fails

AWR1243: Downloading firmware with mmWave Link API

Daniel Zehnder
Intellectual 330 points
Part Number: AWR1243

This is somewhat a continuation from the thread: e2e.ti.com/.../799855
But I wanted to start a new thread here.

The mmwl_powerOnMaster function now works and completes successfully:


rlOsiMutexCreate Callback is called by mmWaveLink
rlOsiSemCreate Callback is called by mmWaveLink
rlComIfOpen Callback Called for Device Index [0]
rlRegisterInterruptHandler Callback is called by mmWaveLink
rlDeviceEnable Callback is called by mmWaveLink for Device Index [0]
rlDeviceMaskHostIrq Callback is called by mmWaveLink
rlOsiSpawn Callback is called by mmWaveLink
rlOsiMutexLock Callback is called by mmWaveLink
rlDeviceUnMaskHostIrq Callback is called by mmWaveLink
rlDeviceMaskHostIrq Callback is called by mmWaveLink
rlOsiSpawn Callback is called by mmWaveLink
rlAsyncEvent Callback Called
rlOsiMutexUnLock Callback is called by mmWaveLink
rlOsiMutexLock Callback is called by mmWaveLink
rlDeviceUnMaskHostIrq Callback is called by mmWaveLink
rlOsiMutexUnLock Callback is called by mmWaveLink
mmWave Device Power on success for deviceMap 1

Question 1: In the document "AWR1xxx_Radar_Interface_Control.pdf" document page 14, it says the host starts a Retry Timer (~1 ms). Can this retry time be increased for debugging? Since sometime I want to print out things that take longer than 1 ms, without causing a time out.

Question 2: The next step is downloading the firmware over SPI and it does not work (MMWL_firmwareDownload). I get the following error:


==========================Firmware Download==========================
Meta Image download started for deviceMap 1
rlOsiMutexLock Callback is called by mmWaveLink
rlOsiSemWait Callback is called by mmWaveLink
rlOsiSemWait Callback is called by mmWaveLink
rlOsiSemWait Callback is called by mmWaveLink
rlOsiMutexUnLock Callback is called by mmWaveLink
MMWL_fileDwld Fail : Ftype: 4
Meta Image download complete ret = -8

Waiting for firmware update response from mmWave device
Firmware update failed for deviceMap 1 with error -8

When I print what's sent over the SPI it's the following (I added the comments):


==========================Firmware Download==========================
Meta Image download started for deviceMap 1
rlOsiMutexLock Callback is called by mmWaveLink
rlComIfWrite Callback Called
1234   // sync
4321   // sync
8105   // opcode
00fa    // length 250
0000   // flags
00a7   // remchunks
0001   // nsbc
7d58   // check sum correct
4080   // msgdata start
00ec
0004
0000
9800
0000
534d
5254
0002
0000
0037
0000
f1f6
beb0
b927
a006
9800
0000
0001
0000
0000
3551
0080
0000
c22c
7120
1ec8
ea8f
13a8
0000
0000
0000
0000
0000
0001
0000
0000
b551
1440
0000
7cc0
a559
e2cf
e5bf
83b0
0000
0000
0000
0000
0000
0004
0000
454d
444e
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
5052
4352
0031
0020
0000
0000
0004
0000
0001
0000
0000
0000
0000
0020
0000
0000
0024
0000
0000
0000
0000
0000
0000
0000
10e7
d0cf
aded
d010
0a01
1400
0c11
000e
0000
0000
0031
0020
0201
0200
0a12
0013
0000
0000
0000
0000
0030
0020
0000
0000
4649   // CRC
rlOsiSemWait Callback is called by mmWaveLink
rlComIfWrite Callback Called
1234
4321
8105
00fa
0003
00a7
0001
7d55
........

and so on. It seems to retry the command a few times and then quit. It looks like this is correct (not sure CRC is correct) but I never get a response from the AWR1243.
I checked the SPI_HOST signal and it never goes high during or after the commands are sent. What could be the issue?

Thanks,
Daniel

  • 0
    TI__Guru 69960 points

    Hi,

    1. You can set ack timeout value before calling rlDevicePowerOn.

    clientCtx.ackTimeout = 5000;

    retVal = rlDevicePowerOn(deviceMap, clientCtx);

    2. After the PowerOn and getting the 'RL_DEV_AE_MSSPOWERUPDONE_SB' Async-event, I suggest invoking another API instead of filedownload to verify that the device responds to the command. Invoke 'rlDeviceGetMssVersion' instead and check if device responds with the ACK.

    Regards,

    Jitendra

  • 0 in reply to Jitendra Gupta
    Intellectual 330 points

    Regarding 1: This timeout is already set to 1000ms. But in the document it says it's 1ms and I get timeout error if I go beyond `1ms:

    Can this be changed to a longer timeout?

    Regarding 2: I now tried to run the function 'rlDeviceGetMssVersion' and I have the same problem no ACK or SPI_HOST=1 from AWR device. Here is the SPI data sent:

    mmWave Device Power on success for deviceMap 1

    rlOsiMutexLock Callback is called by mmWaveLink
    rlComIfWrite Callback Called
    1234
    4321
    81c5
    0012
    0000
    0000
    0001
    7e27
    40e0
    0004
    3149
    rlOsiSemWait Callback is called by mmWaveLink
    rlComIfWrite Callback Called
    1234
    4321
    81c5
    0012
    0003
    0000
    0001
    7e24
    40e0
    0004
    fa36
    rlOsiSemWait Callback is called by mmWaveLink
    rlComIfWrite Callback Called
    1234
    4321
    81c5
    0012
    0003
    0000
    0001
    7e24
    40e0
    0004
    fa36
    rlOsiSemWait Callback is called by mmWaveLink
    rlOsiMutexUnLock Callback is called by mmWaveLink
    mmWave GetMSS Version failed for deviceMap 1 with error -8

    What could be the problem not getting ACK from the AWR device?

    Thanks,

    Daniel

  • 0 in reply to Daniel Zehnder
    Intellectual 330 points

    I can now download the firmware with no issue. The problem was on my system. I accidentally forgot to power up on of the power supplies. The reason why it took a while to figure out is that the mmwl_powerOnMaster still returned successfully. So I was looking at the wrong place.

    Thanks,

    Daniel