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.

AM2434: Flashing SOC initialization binary via UART fails at first step

Part Number: AM2434
Other Parts Discussed in Thread: UNIFLASH

Hello,

we are designing a custom board with the AM2434 chip. When I try to flash SOC Initialization Binary via UART, I got the following error message:

UART uniflash error message

I did all the required steps for flashing to work. I got 'C' on UART0 terminal (which is closed again before attempt to flash). OSPI flash chip is MT35XU512ABA1G12.

Flashing via JTAG interface is working and board is booting in OSPI mode afterwards.

Any ideas what could cause the problem?

Thanks,

Florian

  • Hi Florian Otte,

    Did you change anything in the syscfg settings ? Can you share the updated syscfg settings ?

    Best Regards,
    Aakash

  • Hi,

    I changed OSPI flash and DDR settings according to our hardware.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /**
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --device "AM243x_ALV_beta" --package "ALV" --part "ALV" --context "r5fss0-0" --product "MCU_PLUS_SDK_AM243x@09.00.00"
    * @versions {"tool":"1.17.0+3128"}
    */
    /**
    * Import the modules used in this configuration.
    */
    const flash = scripting.addModule("/board/flash/flash", {}, false);
    const flash1 = flash.addInstance();
    const bootloader = scripting.addModule("/drivers/bootloader/bootloader", {}, false);
    const bootloader1 = bootloader.addInstance();
    const ddr = scripting.addModule("/drivers/ddr/ddr", {}, false);
    const ddr1 = ddr.addInstance();
    const mmcsd = scripting.addModule("/drivers/mmcsd/mmcsd", {}, false);
    const mmcsd1 = mmcsd.addInstance();
    const uart = scripting.addModule("/drivers/uart/uart", {}, false);
    const uart1 = uart.addInstance();
    const debug_log = scripting.addModule("/kernel/dpl/debug_log");
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi Florian,

    I don't believe you need to set -

    debug_log.enableLogZoneInfo as true. Can you try clearing the same and testing it ?

    Also, Pro-tip : You have only 180secs for the device to reset itself and start a new packet/communication channel for XMODEM. I would suggest as soon as you reset, start the communication/transfer via XMODEM.

    Best Regards,
    Aakash

  • Hi Aakash,

    The logging setting is preset in the sbl_uart_uniflash example in SDK9.00.00.35. I did not change anything regarding the logging. But as you suggested, I disabled "Info Log Zone". Unfortunately this does not change the error message.

    Thanks for your tip! Nice to know there is only a 3min time frame after booting to start a UART flash transfer via XMODEM. But I assure you, I am mostly not waiting more than 3min to start the transfer. And if something fails I also power cycle the board and would try again as soon as possble.

  • Hi ,

    Have you verified if the flash_open has been successful MT35XU512ABA1G12 ? Did you run it on this example - https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/latest/exports/docs/api_guide_am243x/EXAMPLES_DRIVERS_OSPI_FLASH_IO.html before reusing the same settings on SBL Uart Uniflash ?

    I still think it maybe a failure in case of Flash Configuration.

    I hope this helps.

    Best Regards,
    Aakash

  • Hi Aakash,

    yes, I tried the OSPI_FLASH_IO example. Firstly I ran OSPI_FLASH_DIAG example to get the Serial Flash Discoverable Parameters (SFDP). I loaded the provided .json-File into the syscfg settings of OSPI_FLASH_IO and all tests have passed. Only things I changed manually are Input Clock Frequency (to 200MHz) and used Protocol (1S-1S-1S), according to the data sheet of MT35XU512ABA1G12.

    The flash device seems to work properly, because flashing it via JTAG is possible. Booting in OSPI mode afterwards is also possible, flashed programs are running successfully.

  • Hi Aakash,

    thanks for your reply. The flash device was chosen based on this document: https://www.ti.com/lit/po/sprt764a/sprt764a.pdf?ts=1707904551984

    -"In OSPI boot mode, the flash must support Octal Output Fast Read (opcode 0x8B) and the 1S-1S-8S transfer
    protocol"

    -"Flash must not boot in octal mode by default"

    We started using the MT35XU512ABA_2_G12, but according to this:

    this chip will not work. And first tests failed. So we switched to MT35XU512ABA_1_G12 and it worked. I changed the settings (Protocol and frequency (200MHz / Input Clock Divider 4 = 50MHz) accordingly to the TI AM243x Flash Selection Guide.

    Nevertheless I am wondering why the error above should have something to do with the flash setting in the sbl_uart_uniflash.Release.hs_fs.tiimage which is not actively executed but just transfered. So the ttimage, whether configured correctly or not, should at least be transfered in the first step?

    As far as I understand only in Step2 the sbl_uart_uniflash.Release.hs_fs.tiimage should be running and loading the actual bootloader program.

  • Hi ,

    Nevertheless I am wondering why the error above should have something to do with the flash setting in the sbl_uart_uniflash.Release.hs_fs.tiimage which is not actively executed but just transfered. So the ttimage, whether configured correctly or not, should at least be transfered in the first step?

    Fair point. Now I am a little curious on which pads on your boards for UART connectivity ?

    Can you really check this FAQ - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1170785/faq-mcu-plus-sdk-am243x-how-to-identify-if-the-device-is-gp-device-or-hs-device

    This will tell you does ROM gives anything out on the UART port and is the data correct at 115200 baud rate ?

    Best Regards,
    Aakash

  • Hi Aakash,

    as requested I executed the linked script. Output:

  • Hi Aakash,

    was the shown output helpful for you in some way to analyze the problem?

  • Hi Florian,

    There is an errata for AM243x. Please see the advisory i2371 in the errata doc https://www.ti.com/lit/pdf/sprz457 .

    The issue might be related to this advisory. 

    Thank you,

    Anita