AWRL6432: UART Bootloader flow: variant differences

Luca Zanuttini

Part Number: AWRL6432
Other Parts Discussed in Thread: UNIFLASH, , IWR6843, IWR1642

Dear TI support team,

I am supporting the UART programming flow of AWRL6432 device. I noted a mismatch in the expected parameter passed to the "CLOSE FILE" (0x22) command between "C:\ti\uniflash_9.1.0\deskdb\content\TICloudAgent\win\ccs_base\mmWave\gen3\mmWaveProgFlash.py" and page 200 of the user manual swru599c.pdf.

Should I use the file type or the storage type?

I have also encountered other mismatches on Gen1 devices, which according to the python script, should all have the file type. However, the SWRA627 states that IWR6843 should have the storage type instead.

Can you please confirm which one is correct?

Is it possible to skip the GET STATUS command and only check that the ACK response is returned? Would this approach be valid for all sensor devices?

Thanks in advance for your support.

Best Regards,

Luca Zanuttini

10 months ago

0 Vignesh Kondapally 10 months ago

TI__Expert 4520 points

Hi Luca,

Thank you for reaching out. Please allow our bootloader expert a few days to look into this and get back to you.

Best,

Vignesh K.

0 Luca Zanuttini 10 months ago in reply to Vignesh Kondapally

Prodigy 50 points

Hi Vignesh,

Is there any news on this topic?

Best Regards,

Luca

0 Luca Zanuttini 10 months ago in reply to Luca Zanuttini

Prodigy 50 points

Hi Vignesh,

Sorry to bother you again, any updates?

Best Regards,

Luca

0 Kristien Everett 10 months ago in reply to Luca Zanuttini

TI__Mastermind 18526 points

Hey Luca,

Sorry for the delay here. I will respond later today with some thoughts and suggestions.

Regards,

Kristien

0 Kristien Everett 10 months ago in reply to Kristien Everett

TI__Mastermind 18526 points

Hey Luca,

Luca Zanuttini said:
Should I use the file type or the storage type?

For AWRL6432, the CLOSE DOWNLOAD command does not require a file type as it indicates the end of the file download. As for the storage type, in most cases, you should be using Close Download (SFLASH) - i.e., 0xAA | 0x0007 | CHK_SUM | 0x22 | 0x2 - unless downloading to SRAM.

Luca Zanuttini said:
Is it possible to skip the GET STATUS command and only check that the ACK response is returned? Would this approach be valid for all sensor devices?

The GET STATUS command is not required, so you could exclude it if download times are significant. However, as shown by the Python scripts, we only call GET STATUS if a NACK is received with the last command sent, so this should little to no impact on download times in the first place.

Regards,

Kristien

0 Luca Zanuttini 10 months ago in reply to Kristien Everett

Prodigy 50 points

Hi Kristien,

Thank you very much for your response.

Is the CLOSE DOWNLOAD the same for all sensor devices? If so, does that mean there is a mistake in the Python scripts that use the file type as a parameter for CLOSE DOWNLOAD? Should I be concerned about other known mistakes in your scripts?

Is the IWR1642 Bootloader Flow an exception? I see from SWRA563 - June 2017 (https://www.ti.com/lit/an/swra563/swra563.pdf) that the filetype is passed as paremeter instead.

Best Regards,

Luca

0 Kristien Everett 10 months ago in reply to Luca Zanuttini

TI__Mastermind 18526 points

Hey Luca,

The CLOSE DOWNLOAD command is not the same for all radar devices. For Gen1 devices such as IWR1642, the file type (META_IMG1, META_IMG2, META_IMG3, or META_IMG4) is required as a part of the CLOSE DOWNLOAD command. Note: xWR18xx and xWR68xx devices are an exception to the Gen 1 family and require the storage type as a part of the CLOSE DOWNLOAD command. For Gen 2 devices, it utilizes UART+XMODEM to transfer images, so this does not follow the custom commands of other generations. For Gen 3 and 4 devices, the storage type (SFLASH or SRAM) rather than file type is specified for the CLOSE DOWNLOAD command.

Hopefully that clarifies the differences on the bootloader commands, but let me know if you have any other questions.

Cheers,

Kristien

0 Luca Zanuttini 10 months ago in reply to Kristien Everett

Prodigy 50 points

Hello Kristien,

Sorry to insist, but I noticed that the script for gen3 sets the filetype for the CLOSE DOWNLOAD command, and not the storage type:

Is this a mistake in the script?

I also noticed in the script for Gen1 devices that the STATUS command is always sent regardless of the ACK response. Can I skip the STATUS command instead like Gen3 and Gen4 devices?

Best Regards,

Luca

0 Kristien Everett 10 months ago in reply to Luca Zanuttini

TI__Mastermind 18526 points

Hey Luca,

Luca Zanuttini said:
Is this a mistake in the script?

I double checked internally with our UniFlash team, and it does appear this is a bug in the UniFlash implementation. However, this does not cause any issues during file download as specifying the file type for the OPEN FILE command is more important for the file download.

Luca Zanuttini said:
I also noticed in the script for Gen1 devices that the STATUS command is always sent regardless of the ACK response. Can I skip the STATUS command instead like Gen3 and Gen4 devices?

You should be able to exclude the GET STATUS command as the returned status is not utilized during the download process in the UniFlash scripts.

Cheers,

Kristien

0 Luca Zanuttini 10 months ago in reply to Kristien Everett

Prodigy 50 points

Hi Kristien,

I look forward to your feedback.

In the meantime, can you also confirm whether the file type or the storage type should be passed to the CLOSE COMMAND for IWR6843? In fact, it is also a Gen1 series, however SWRA627 states that the storage type should be used rather than the file type. By the way, are you referring to bootloader flow application note or to internal docs? I am concerned that the AN such as SWRA627 might be incorrect due to a copy and paste issue.

Anyway, I agree with you that this should not have any impact on the programming. I just want to ensure that everything is compliant with the official specifications.

Best Regards,

Luca

0 Kristien Everett 10 months ago in reply to Luca Zanuttini

TI__Mastermind 18526 points

Hey Luca,

I will note that the device generations are not always clearly defined, so there can be some strange exceptions.

Luca Zanuttini said:
In the meantime, can you also confirm whether the file type or the storage type should be passed to the CLOSE COMMAND for IWR6843?

The xWR68xx and xWR18xx devices are an exception to the Gen 1 devices as they were released later than xWR12xx, xWR14xx, and xWR16xx devices. For xWR68xx and xWR18xx devices, the close command does require a storage type be specified rather than the file type.

Luca Zanuttini said:
By the way, are you referring to bootloader flow application note or to internal docs? I am concerned that the AN such as SWRA627 might be incorrect due to a copy and paste issue.

I'm referring to the following documents:

12xx, 14xx, 16xx - Section 3.3 Supported Commands and Format (https://www.ti.com/lit/an/swra563/swra563.pdf)
18xx, 68xx - Section 3.3 Supported Commands and Format (https://www.ti.com/lit/an/swra627/swra627.pdf)
L14xx, L64xx - Section 4.5.2 Bootloader Commands (https://www.ti.com/lit/ug/swru599c/swru599c.pdf)
L68xx - Section 4.2.4.2 UART Bootloader Commands (https://www.ti.com/lit/ug/swru621/swru621.pdf)

Let me know if you have any other questions.

Cheers,

Kristien

0 Luca Zanuttini 10 months ago in reply to Kristien Everett

Prodigy 50 points

Hello Kristien,

I noticed that after programming an image file I cannot download a new one without restarting the serial communication (including a reset pulse). Is this expected? I mean, is it possible to download multiple image files sequentially, like:

Open file (Image1)

Send data (Image1)

Close file (Image1)

Open file (Image2)

Send data (Image2)

Close file (Image2)

Instead of:

Open file (Image1)

Send data (Image1)

Close file (Image1)

Reset pulse

Wait ACK

Open file (Image2)

Send data (Image2)

Close file (Image2)

Best Regards,

Luca

0 Kristien Everett 10 months ago in reply to Luca Zanuttini

TI__Mastermind 18526 points

Hey Luca,

For Gen3 devices, it is expected that you will need to reset the device between image loads as per the instructions for flashing the Secondary Boot Loader and a backup image. For Gen 4 devices, I will need to double check if a reset is still needed, but it should not need a reset if attempting to flash multiple images at once.

Regards,

Kristien

0 Luca Zanuttini 10 months ago in reply to Kristien Everett

Prodigy 50 points

Hi Kristien,

Thank you very much for the info.

Based on the last link you shared, it seems that an image file size can be up to 512KB. However, from the python script, I see the following values instead:

Gen1, Gen3:

MAX_FILE_SIZE = 1024*1024
MAX_APP_FILE_SIZE = 166912

Gen4

MAX_FILE_SIZE = 512*1024*1024
MAX_APP_FILE_SIZE = 5120*1024*1024

Is it a bug of the script or is the partition size not always fixed to 512KB? I assume that the OPEN FILE commands returns NACK if the address is outside the expected partition, can you confirm this?

Thank you again for your help.

Best Regards,

Luca

Sensors

Sensors forum

AWRL6432: UART Bootloader flow: variant differences