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.

AWR1243BOOST: Firmware Download over SPI

Part Number: AWR1243BOOST
Other Parts Discussed in Thread: IWR1443BOOST, AWR1243, UNIFLASH, AWR1443

Hello,

I am testing the firmware download over SPI using an AWR1243BOOST board. I am using the BOOST board with the SOP pins set to functional mode, and I have never flashed the SFLASH on-board, so the device firmware must be downloaded over SPI.

When I raise the NRST signal, I do not receive a corresponding Host IRQ. It is my understanding that when NRST is raised, the device should pull up Host IRQ to indicate that it is ready to receive a firmware patch over SPI interface.

Can you advise what behavior I should expect?

Best,
Antonio

  • Do you have a DEVPACK board? Have you used it with mmWave Studio before?

    thank you
    Cesar
  • I have used other AWR1243BOOST boards and IWR1443BOOST boards with our in-house FPGA acquisition platform. Everything works properly.

    Right now I am just testing the firmware download over SPI. That is why I am using a fresh out-of-the-box AWR1243BOOST board which has never been flashed before.

  • Antonio,

    Can you provide more information on your hardware setup? Are you using an external processor to interface to your PC? Or are you using the mmWave Dev-Pack to interface to your PC?

    When using the mmWave Dev-Pack, the firmware is sent over UART from the host PC to the AWR1243BOOST EVM.

    Regards,
    Kyle
  • I am using an FPGA to interface with the AWR1243BOOST.
  • Hi Antonio,

    Can you please confirm you are referencing all of the AWR1243 boot ROM documentation we have on ti.com already: 

    Just to confirm the basics: 

      • Did you confirm that that QSPI NOR flash on the EVM are actually in a formatted state? Some of our EVM are shipped with the out of box demo already flashed to the NOR flash memory. If the AWR1243 boot ROM detected a valid image on QSPI it will not branch to the the SPI bootmode.
      Did you confirm the state and timing of the SOP[2:0] pins during power on reset sequence (see AWR1243 data manual) ?
      • The jumpers on the EVM will drive this, but I am not sure if you are mastering these from an external device from your description. 

    If you can, I would recommend using Uniflash with the Devpack hardware to format the QSPI flash on these target EVM over UART from a PC host. If you only have custom hardware available, you can create a similar utility using the Bootloader Flow document above. 

    Your understanding of the initial SPI_HOST_INTR_1 toggling high after initial boot ROM execution is correct. 

    According to the Bootloader Flow document, Figure 9 - Bootmode - SPI, as soon as MSS ROM bootup completion is finished, the AWR1243 device should send an AWR_AE_DEV_MSSPOWERUPDONE_SB message to the host. This is also described in the ICD Figure 3.2 - Flow Diagram (Asynchronous Events). Just like all other Device to Host SPI transmissions this should start with an IRQ issued on the SPI_HOST_INTR_1 line. 

    So if you are not seeing that IRQ then either the ROM is branching before SPI boot mode is entered or the ROM is failing to complete execution for some reason. 

    Thanks,

    Randy

  • Hi Randy,

    Those are the two docs I have been using as a design reference.

    The SOP pins are set using the jumpers on the EVM. SOP[0] is pulled high, SOP[1:2] are low for functional mode.

    This is the behavior I observe:
    1) If the QSPI flash has a valid firmware image: Upon releasing NRST, the AWR chip toggles the interrupt line and I receive AWR_AE_DEV_MSSPOWERUPDONE_SB. I can then proceed with the sequence of commands outlined in Section 5.22 of the Radar Interface Control.
    2) If the QSPI flash does NOT have a firmware image: Upon releasing NRST, nothing happens and there is no interrupt toggle.
    2a) I attempt to send AWR_DEV_FILE_DOWNLOAD_SB anyway. The first message receives no response from the AWR. On the first retry attempt, the radar raises the interrupt line. I send the CNYS sequence, but the radar does not transmit any form of message (ACK, ERROR, or ASYNC_EVENT).

    I have further formatted the QSPI flash using Uniflash tool to make sure it is empty - I still observe behavior (2).

    Any further debugging ideas? One idea that occurred to me is that even the presence of an empty QSPI flash causes incorrect bootup behavior on the AWR chip - is that possible? Is SPI firmware download verified to work on the AWR1243BOOST board?

    Best,
    Antonio
  • Any update on this topic? Can you confirm whether SPI firmware download is verified to work on the AWR1243BOOST boards?
  • Hi Antonio, 

    I will need a few days to get back to you on this. I am checking this behavior with our boot loader designer now. 

    Thank you

    -Randy

  • Sure thing, thanks Randy. I appreciate your help with this.
  • Hi Randy, were you able to get any more information on this issue?

    Thanks,
    Antonio
  • Hi Antonio,

    Not yet. Still working on getting an answer for you. Will need a few more days at least.

    Thank you,
    -Randy
  • Randy,

    Any updates or findings from your end?

    Best,
    Antonio
  • Hi Antonio,

    I am trying to replicate this issue on my end. Can you please verify whether you are working with an AWR1243 device or an AWR1443 device? Our boot ROM team has explained to me that the behavior you are seeing is actually expected on a AWR1443 device, but not on an AWR1243 device. I do not think we document that difference clearly in any external documentation though.

    Thanks,
    -Randy
  • Hi Randy,

    Great to hear from you.

    The device markings on our chip package say:
    XAWR1243
    1G

    7AZDSG9
    964D ABL G1

    so it certainly seems like it should be an AWR1243. What you are saying is very interesting - it seems like it could not be a coincidence. Is there any other way to check the ROM version? Could it be possible for the ROM to be set incorrectly?

    Best,
    Antonio
  • We have successfully resolved this issue. It turned out that the problem was that our host was holding CS low upon bootup. This caused the AWR device to not issue an IRQ. Having fixed this issue we can now receive the IRQ and async event indicating MSS boot.