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.

the difference between XWR1642 and 1243 in the spi boot mode

Other Parts Discussed in Thread: AWR1642, AWR1243

hi,
I used the mmwavelink_example in the mmwave_dfp_01_02_05_01 to execute successfully on the 1243 EVM。 Now I need to use the example to run on the 1643 EVM, 1642 using spi bootmode.But I had some problems, so I wanted to consult,
1 Does 1642 support spi bootmode? What is the difference between 1243 and 1642 in the spi bootmode?
2 After I erased the flash of 1642 EVM, I didn't detect the high level in the pin of HOST_INTR, so I removed the flash chip on the EVM, then there is a high level in the HOST_INTR pin。 Is these normal?
3 Then I transfered the firmware successfully, but I found that the 1642 didn't work properly。 So I captured the spi data with the logic analyzer and found that 1642 returned a powerup asynchronous event, instead of the booterrorstatus asynchronous event, just like the 1243. What else do I need to do to start 1642 after the firmware transfer?
Thank you in advance for your answer.

  • Hello,

    1. AWR1642 supports SPI bootmode when it doesn't detect sflash connected with it.

    2. Answer:1

    3. I would request you to refer bootloader appnote for SPI bootmode for correct sequence.

    http://www.ti.com/lit/pdf/swra551 (section 2.2)

    Regards,

    Jitendra

  • Jitendra

    Thank you for your prompt reply. But the third answer didn't solve my problem, I just did it according to the document(section 2.2). The whole process is correct when the example is executed on AWR1243, But there is a problem when the example is executed on XWR1642. The XWR 1642 returns a wrong data at the red box which is marked 2 in the figure,after firmware file download. After careful analysis of the data, it is found that the the data is the same as that in the red circle box which is marked 1 in the figure. In addition, AWR1243 is a es3.0 chip. Is it related to the chip version number?

    1642_论坛.docx

  • Jitendra

    Thank you for your prompt reply. But the third answer didn't solve my problem, I just did it according to the document(section 2.2). The whole process is correct when the example is executed on AWR1243, But there is a problem when the example is executed on XWR1642. The XWR 1642 returns a wrong data at the red box which is marked 2 in the figure,after firmware file download. After careful analysis of the data, it is found that the the data is the same as that in the red circle box which is marked 1 in the figure. In addition, AWR1243 is a es3.0 chip. Is it related to the chip version number?

  • Hello,

    So you are saying what with AWR1642 after SPI firmware download you received the message which is of sub-block ID AE_DEV_MSSPOWERUP_SB not AE_MSS_BOOTERRORSTATUS_SB. But what is after that: does you application (which you loaded over SPI) loads up or run after this??

    Regards,

    Jitendra

  • After SPI firmware download I received the message is ofsub-block ID AE_DEV_MSSPOWERUP_SB. Then  I found that my application doesn't load up. AWR1642 didn't change anything. So  I thought it didn't work. That is to say AWR1642 loaded failed over SPI.

  • I have no idea how to explain this phenomenon.  Do you have any suggestions?Looking forward to your reply!!!

  • Hello,

    With AWR1642 (no flash connection), which firmware file you are loading over SPI? It should be AWR1642 application in metaImage format.

    I suspect you are trying to load AWR1243 firmware over SPI to AWR1642.

    You can use OOB demo metaimage binary file from mmWave SDK to load over SPI.

    And after application metaimage file loaded to device over SPI you need to connect TeraTerm/Serial port (application/UART COM PORT) to look for CLI prompt which is output from OOB demo when it boots.

    Another way to verify if application image is booted: connect MSS core from CCS and try to write on address '0x0', if you are able to write then this is application image loaded else ROM image (which is not writable).

    Regards,

    Jitendra

  • Hello, 

    I am sure I load AWR1642 firmware over SPI to AWR1642. The firmware is  xwr16xx_mmw_demo.bin, which I find it in the SDK. The mmwavelink_example in the mmwave_dfp_01_02_05_01, used the .h instead of .bin. The content of the two files is the same but the format is different. I converted file format just like the mmwavelink_example. And tried two file formats. 

    In addition, we try to load the file with data output from the canfd interface from the flash, and load the file without data output from the canfd interface through the SPI

  • Hello,

    I suspect that converted *.h file may not be in correct format which may be causing this error.

    Could you try this xwr16xx_mmw_demo.bin from mmwave studio which uses binary file format to load over SPI interface to AWR device?

    I could understand the your last statement about CANFD interface.

    user6278526 said:
    In addition, we try to load the file with data output from the canfd interface from the flash, and load the file without data output from the canfd interface through the SPI

    Regards,

    Jitendra

  • Hello,

    I missed to inform you about one point for SPI boot mode.

    MetaImage binary file contains the 4 bytes of CRC at the end. This 4 bytes should not be sent to the device over SPI during this mode (SPI boot).

    I have attached the script here which converts the MetaImage to header file (without 4B CRC). output of this script can be used with mmWavelink_example to load the firmware to AWR1642 over SPI.

    metaImage_to_header_convertor.zip

  • I've noticed the difference about CRC. At the same time, I have converted the MetaImage to header file (without 4B CRC).  I tried this way, but it didn't work. So what can I do now?

  • I've already paid attention to CRC. The 4 bytes  of CRC didn't sent to the device over SPI during this mode (SPI boot). 

    It is operated according to the way you said. But it failed. So what can I do?