• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 545 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AWRL6432: BOOTROM UART download sequence, "Open Download" command to internal SRAM doesn't work. Is it a bug?

James Austrial
Expert 4160 points
Part Number: AWRL6432
Other Parts Discussed in Thread: UNIFLASH

Hi,

HW: AWRL6432 ES1.0

The BOOTROM supports UART download sequence like below.

First we send the “UART break” from HOST and AWRL6432 response a ACK MSG. ==> This is OK

After that, we send “Open Download” command from HOST but AWRL6432 response a NACK MSG.  ==> This is an issue.

The "Open Download" destination storage is set as AWRL6432 internal SRAM.

We suspect UART download sequence "Open Download" to SRAM command is not supported. Could you clarify it?

You can also use Uniflash to reproduce the issue:

Step 1: Specify target memory as SRAM

Step 2: Start to download image, the AWRL6432 reply NACK ([ERROR] Cortex_M4_0: Nack Received, Err Code: 0x0000020000000000)

We also try to use serial port tool to send command / get response between host and AWRL6432.

The situation is the same.

  • 0
    TI__Genius 13816 points

    Hey James,

    I will have to check internally to verify that all UART commands to the SRAM are supported. I will try to get back to you within the next day or two.

    Regards,

    Kristien

  • 0 in reply to Kristien Everett
    TI__Genius 13816 points

    Hey James,

    There are two requirements for loading an image over UART:

    1. The device must be in functional mode
    2. The SFLASH device on the board must be absent.

    The SFLASH absence requirement is mentioned on p. 187 and 188 of the TRM. Unfortunately, your best bet for ensuring the SFLASH is absent is to remove the MX25V1635FZNQ03 from the board. For previous generation devices, there was a resistor from the power supply to the VCC of the flash device that could be desoldered, but that is not present on the low-power devices. I understand that this requirement may be obtrusive, so I will look into whether the bootloader flow could be modified or that resistor is added back in for future devices.

    Regards,

    Kristien

  • 0 in reply to Kristien Everett
    TI__Expert 4160 points

    Hi,

    From my point of view, the follow conditions/design in Boot ROM is strange:

        The SFLASH device on the board must be absent.

    The UART downloading from PC is usually used as part of image flashing. 

    That means PC transfer a small program to target by UART and then this small program manipulate flash and communicate with PC to do the image flashing.

    Could you double confirm this strange pre-condition to Boot ROM designer?

  • 0 in reply to James Austrial
    TI__Genius 13816 points

    Hey James,

    It has been confirmed that the SFLASH device must not be present on the board to boot over UART. The default functional mode behavior of the bootloader is to load the previously downloaded user application in the SFLASH to the internal SRAM using QSPI. As of right now, there is no way to force the bootloader to load over UART while the SFLASH device is present. I will talk with our bootloader team to see if there is any other solutions or temporary workarounds.

    Regards,

    Kristien