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.

IWR1443: IWR1443 integration into our devices

Part Number: IWR1443
Other Parts Discussed in Thread: TIDEP-0091, AWR1243, UNIFLASH, IWR1642
Dear Texas Support Team,
 
We are actually working on the integration of the IWR1443 mmWave sensor in our electronic dispositive.
Since our main controller is equipped with a large nonvolatile storage, we intend to reload binary image into the IWR1443 RAM at boot time (in our architecture, no QSPI Serial Flash will be present !)
 
According to chapter §6.8.2 of the IWR1443 datasheet (see extract below), the bootloader should enable its SPI interface at startup to wait for image transfer.
Unfortunately, I cannot find in the IWR1443 literarture the description concerning the SPI protocol to perform this image transfer and to run afterward the user application !
Could you please provide us any document in order to realise this operation ?
-----------------------------------------------------------------------------------------------------------
6.8.2 Functional Mode
 
"In Functional Mode, the Master System’s bootloader looks for a valid image in the serial flash memory,
interfaced over the QSPI port. If a valid image is found, the bootloader transfers the same to Master
System’s memory subsystem. If the device firmware image is found, it gets transferred to the Radar
section’s memory subsystem.
If a valid image (or the QSPI Serial Flash is not found), the bootloader initializes the SPI port and awaits
for the image transfer. This operation comes handy for configurations where the IWR1443 is interfaced to
an external processor which has its own nonvolatile storage hence can store the user application and the
IWR1443 device’s firmware image."
 
-----------------------------------------------------------------------------------------------------------
 
 
Best regards,

 

  • Hello Jean-Paul,

    The TI Design on Power Optimized Level Sensor (TIDEP-0091) uses SPI off the IWR1443 to communicate with an MSP432 Launchpad. Example code is included in the Software Design Files.

    Is this what you are asking for? Let us know if it doesn't work and please provide more information about your application.


    Cheers,
    Akash
  • Hello Akash,

    Thanks for your feedback...

    My undestanding is the project you pointed out (TIDEP-0091) implements a custom SPI protocol to transmit data between the application downloaded into the IWR1443 and the MSP432 Launchpad ! Not really what I am searching for !

    Instead, I am looking for the SPI protocol (in ROM) used by the IWR1443 bootloader.
    Searching in the IWR litterature, I identified an application note (IWR12xx Bootloader Flow) describing the sensor boot loader behavior.
    The chapter $2.3 (See below) just introduces the "Radar Interface Control document" that should describe in details the "Bootloader SPI Communication Protocol".
    I am pretty sure all information I need to download the binary image into the IWR1443 RAM is available in this document, but I cannot find it in the TI documentation database !

    ------------------------------------------------------------------------------------------------------------------------------
    2.3 Bootmode – SPI

    In functional mode, if no valid image header is found in the predefined SDF location, the bootloader will
    enter the SPI based bootloading mode.

    This involves the following steps:

    • Pinmux the SPI pins - [SPI_MOSI: Ball R8, SPI_MISO: Ball P5, SPI_CLK: Ball R9, SPI_CS_N: Ball R7
    and SPI_HOST_INTR: Ball P6 of AWR1243 device]

    • Follows the “Communication Protocol” as defined in the Radar Interface Control document to
    communicate with an external host to receive the images to be loaded as message packets over SPI.
    ------------------------------------------------------------------------------------------------------------------------------
  • Hello Akash and team,

    What my customer wants to do is different from the example level sensing project. They want to use IWR1443 with no QSPI flash and the firmware to be loaded by the host after power-up. According to the device datasheet section 6.8.2, the ROM bootloader will initialize the SPI and wait for the customer firmware to be loaded over SPI.

    The simple question is, does TI have an example host application that would download a firmware over SPI by communicating with the IWR1443 ROM bootloader?

    My customer looked for some information and found the Radar Interface Control document in the DFP which does not give a top-level view of this flow. We also have the AWR1243 Bootloader Flow application report that documents the flow in section 2.3. But what's troubling is this application report only refers to the AWR1243 device when the Radar Interface Control document refers to AWR1xxx, so all the family devices, and for example the mmwavelink Doxygen documentation says the rl_device.c:rlDeviceFileDownload() function is valid for AWR1243 only.

    Back to the simple question above: the DFP includes the mmw_example.c example which looks like what my customer needs. Is it applicable to IWR1443?


    Thanks,
    François.
  • Hello Francois,
    The AWR1243 Bootloader document, and the Radar Studio ICD list the message format, for the 1243. There are no examples of this being done for IWr1443. I have asked the boot rom designer. Another note, the ES3 devices, need a BSS Rom patch, I have only tested this coming from QSPI for an IWR1443.

    We will continue to follow up with the designers, but I strongly suggest your customer put the QSPI interface on their initial board. Maybe after initial bringup, the device could be removed in a board spin. This would allow them to utilize the Uniflash program, and modified Data Capture demo for radar testing.

    You can try this with an EVM, if you have the appropriate command and code built up.
    I don't know of examples using IWR1443 and SPI boot.

    Regards,
    Joe quintal
  • Hello Joe,

    Thank you. Let's close the discussion then. On a side note, maybe this feature should be removed from the IWR1443 datasheet (section 6.8.2) unless we intend to support it. There is also a 1-line statement in the IWR1642 datasheet (section 8.1, Flexible boot modes).

    Best regards,
    François.