IWR6843AOP: mmWave Bootload to RAM via SPI

Hello,

First, I would like to link our bootloader flow document for anyone else looking at this thread for information.

You will need to make sure your set up is the EVM board + our mmwave icboost board adn the flash will need to be depopulated.

You can find an example implementation of the mmWaveLink API to load via SPI in the DFP download at https://www.ti.com/tool/MMWAVE-DFP. Once downloaded this example can be found at "C:\ti\mmwave_dfp_01_02_06_03\ti\example\mmwavelink_example\mmw_ecample.c". This example is for the AWR1243, but the mmwLink API should be the same for IWR6843 and some of the variables need to be changed.

Please let me know what questions you have after looking at this example.

Thanks,

Angie

Angie,

Thanks for getting back to me on this.

I've spent the day looking through the mmwave dfp code (mmw_example.c, etc) and I'm coming to the conclusion that whatever downloader code I'm reading is very different to the protocol described in the Bootloader Flow document. The implementation is certainly very convoluted for such a simple protocol.

Basically, it doesn't answer any of my original questions.

Would you be able to answer them for me please? I have a very tight schedule for completing this task, so I hope you'll be able to find someone to give it more urgent and complete attention.

Just to recap: I'm trying to write an application in C (on a RPi CM4 board) to download an image file to an IWR6843AOP RAM via SPI.

Thanks,

IanB

Hi Ian,

Our team has been looking into this request and will get back to you by next Monday. 

Thank you,

Angie

Hi Ian,

The example I gave is a working example of the SPI protocol for AWR1243. A more up to date example can also be found in the 2nd gen DFP package for the AWR2243 at https://www.ti.com/tool/MMWAVE-DFP when you download MMWAVE-DFP-2G and navigate to \mmwave_dfp_02_02_04_00\ti\example\mmWaveLink_SFlash_FW_Example. This is specifically an example loading over SPI.

The more detailed documentation can be found at mmwave_dfp_02_02_04_00\docs in the mmWave-Radar-Interface-Control.pdf in the section titled "Communication Protocol". 

1. How do I poll for an ACK response over SPI when clock pulses are sent in bursts of 16-bit SPI transactions (ie. bounded by Chip Select assert and de-assert), when an ACK Response comprises a 16-bit, an 8-bit, and a 16-bit element (in that order)? Do I need to wait for a certain period of time before polling for an ACK response, or do I keep sending clock pulses until I receive the byte sequence 00, 04, 0C, 00, CC?

Please see the Communication Protocol in the mmWave-Radar-Interface-Control.pdf. 

2. Similarly, how do I poll for a STATUS response?

There is a RF_STATUS_GET_MSG and DEV_STATUS_GET_MSG. The subblocks of what the resposes to these status checks could be is documented under Radar Functional APIs. 

3. If there is an ACK response, then is there also a NAK response in the event of failure? If so, where is this detailed?

There is also a NACK, this is documented in the mmWave-Radar-Interface-Control.pdf 

4. Do I need to poll for an ACK response after the OPEN command?

Every command will have some sort of response (either ACK, NACK or a command specific response). However, there is no OPEN command in the SPI communication protocol.

Hi Ian,

We're out for the holidays now. Please give us until the New Year to address this. If you do not hear a response by then, feel free to ping this thread again.

Best,

Nate

Hi Nathan

Have you created an opportunity to have a look into this CRC issue this New Year?

To recap, the previous post contains a byte stream (in the order in which they are received) but I cannot find a CRC calculation which produces the CRC appended.

Once I know how this is calculated at the TI end, I can then use the same means to calculate CRCs for attachment to download messages.

I hope you'll be able to get back to me with an answer very shortly.

Regards,

Ian

Hi Ian,

Thank you for pinging this thread, I am going to get back to you in the next 48 hours on this topic.

Thanks again,

Angie

Hi Angie,

Sorry, but this needs to be addressed Today. 48 hours will move us into Saturday ... which means Monday at the earliest.

The latency on this is already too long.

At the moment I have 'turned off' CRC in FLAGS until this issue is resolved, but I can only successfully transmit 7 data chunks and receive ACKs. The 8th message elicits no response from the radar device.

Do you recognise this trait? Is there any reason why the full image download cannot be made without CRC protection?

I have also read (MMWave ICD Rev 2.23, page 20) that the preferred "chunk size" is 232. I have formed the opinion that the overall message size should be no more than 232 bytes, leaving a maximum chunk size (ie the image payload size) of 204 bytes (without CRC) or 200 bytes (with CRC32).

If I transmit messages greater than 232 bytes I see what appears to be response data on the SPI MISO line. For example, if I send 232 bytes then all bytes on MISO are 0xFF. If I send 236 then I see the final bytes on MISO are 0xDC 0xBA 0xAB 0xCD. If I send 240 bytes then I see the final bytes on MISO are 0xDC 0xBA 0xAB 0xCD 0x81 0x16 0xFF 0xFF.

Is this to be expected?

Regards,

Ian

Hi Ian,

Section 5.21.1 (page 309) of the mmWave-Radar-Interface-Control.pdf details the MSSPOWERUPDONE contents. Section 4.25 shows the larger package the message would be a part of. Page 10 has some more information on the CRC value.

I am also checking internally to see if there is any more documentation on this I can share.

Thank you,

Angie