• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 660 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:

Linux/AWR1243BOOST: mmWave Studio alternative

Linux/AWR1243: Trouble booting Radar/RF subsystem

Erik Reikes
Prodigy 130 points
Part Number: AWR1243

Tool/software: Linux

We have a custom AWR1243 application and I am attempting to implement the mmw_example.c functionality on our embedded host.

I used as a starting point for my port the function stubs in rls_studio.c and implemented the SPI open/read/write as well as the OS function callbacks, etc.  This is all from DFP release 01.02.00.01

I can communicate with the AWR1243 reliably and I'm able to reset the device and the the 0x5000 RL_MSS_POWERUP_COMPLETE message comes through..

Interestingly I do get a set bit in the second to last byte of the MSS_POWERUP_STATUS field and all 0's in the BOOTTEST_STATUS field.  Depending on the endian swaps for the MSS_POWERUP_STATUS field that flag is either CERT FIELD VALIDITY FAILURE or CERT FIELD INVALID DECRYPT KEY INDEX.  I'm not sure as table 6.3 has 30 bits in a bitfield that map to an 8 byte with whatever weird 16 bit endian swap is going on.

I am able to successfully download the metaimage patches from the above refernced DFP release and I then get a 5005 message 

AWR AE MSS BOOTERRORSTATUS SB with all 0's,  the mmw_example code treats this as MSS boot success, so I assume this is ok.  It is concerning to me that none of the BOOTTEST_STATUS bits are set as the ICD says bits set indicates passed.

The mmw_example next sets the CRC which succeeds.

So far so good.

The next step is where the probelem is.  MMWL_rfEnable is called which calls rlDeviceRfStart. 

I can see the ack come back from rlDeviceRfStart, but I never see the async message from the BSS system.  If I bypass the application exit, all subsequent messages meant for the BSS read back nothing but 0xFF's, but other messages destined for the MSS succeed.

Is there some step I'm missing?

Are there some other messages I could pull to query status of the BSS?

Any suggestions at all at this point would be appreciated. 

Thanks.

  • 0
    TI__Guru*** 149204 points

    Hi,

    Will get back to you early next week

    Thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 130 points

    Thanks.

    As an additional data point, we have a feeling that its not taking the patch file correctly.  All the messages go down and are acked and it reboots (or at least it sends the 5005 message).  We looked into detail if there was some sort of endian swap problem, but it looked correct. 

    We are actually doing a 16 bit endian swap as it goes out the SPI peripheral (and comes back in).  When we turn this off we no longer see syncs or message flow, so we believe that is correct.  I also inspected the provided metaimage bin file with a hex editor and compared against the included h file for the metaimage.  It looks like little endian uint16's which if the M4 SPI peripheral is consuming SPI data MSB first would be correct for little endian architecture.  Our management processor is also little endian.

    With the ES3 chips is the default ROM supposed to emit that RF start message?  When I turn off firmware download and boot without a patch, ours do not do this.

    Thanks.

  • 0 in reply to Cesar
    Prodigy 130 points

    Hi Cesar,

      Any update on my questions re: bootloading?  We are pretty well stuck and going through SPI logs byte by byte at this point.  The big difference I see between working/non working setups is the error bits set in the power on message.  What could cause those?  do you have any advice as to the bit/byte ordering so that we can be sure which error is being flagged?

    Thanks.

  • 0 in reply to Erik Reikes
    TI__Genius 15005 points
    Hi Erik,

    Would you be able to capture the traffic on the SPI bus using a logic analyzer? Alternatively, would you be able to let us know the exact sequence of bytes sent out on the bus for the first few messages? (The logic analyzer trace would be much more useful to debug).

    Is your host little-endian or big-endian?

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    TI__Genius 15005 points
    Hi Erik,

    Just following up - any luck getting these SPI traces?

    Best Regards,
    Anand
  • 0 in reply to Anand Gadiyar
    Prodigy 130 points
    Hi Anand,
    Yes we were able to get SPI traces and detected no differences in download from our evaluation board compared to our new hardware.

    The good news is that this caused me to look much more in depth at the hardware. I found that the clock generator that was supposed to be feeding 40MHz to the AWR1243 was mis-configured and was actually sending 50MHz to the AWR1243 due to a fat-fingered I2C command.

    The MSS would operate fine at this frequency, but the BSS failed to boot up. Perhaps that's what the extra bit that was set in the power up message was indicating. In any case, we are over the hump in terms of patch download and are now in the process of validating our RF design.

    Thanks.