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

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.

/**
 * 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");
const mpu_armv7   = scripting.addModule("/kernel/dpl/mpu_armv7", {}, false);
const mpu_armv71  = mpu_armv7.addInstance();
const mpu_armv72  = mpu_armv7.addInstance();
const mpu_armv73  = mpu_armv7.addInstance();
const mpu_armv74  = mpu_armv7.addInstance();
const mpu_armv75  = mpu_armv7.addInstance();

/**
 * Write custom configuration values to the imported modules.
 */
flash1.$name                         = "CONFIG_FLASH0";
flash1.protocol                      = "1s_1s_1s";
flash1.device                        = "CUSTOM_FLASH";
flash1.fname                         = "MT35XU512ABA1G12";
flash1.flashManfId                   = "0x2C";
flash1.flashBlockSize                = 131072;
flash1.cmdBlockErase3B               = "0xD8";
flash1.cmdSectorErase3B              = "0x20";
flash1.cmdRd                         = "0x03";
flash1.cmdWr                         = "0x02";
flash1.dummyClksCmd                  = 0;
flash1.dummyClksRd                   = 0;
flash1.proto_isAddrReg               = false;
flash1.dummy_isAddrReg               = false;
flash1.strDtr_isAddrReg              = false;
flash1.resetType                     = "0x30";
flash1.deviceBusyType                = "0";
flash1.cmdExtType                    = "NONE";
flash1.srWel                         = 0;
flash1.xspiWipRdCmd                  = "0x00";
flash1.xspiWipReg                    = "0x00000000";
flash1.idNumBytes                    = 5;
flash1.fourByteEnableSeq             = "0x36";
flash1.peripheralDriver.$name        = "CONFIG_OSPI0";
flash1.peripheralDriver.dmaEnable    = true;
flash1.peripheralDriver.inputClkFreq = 200000000;

bootloader1.bootMedia = "MEM";
bootloader1.$name     = "CONFIG_BOOTLOADER_MEM";

ddr1.$name                    = "CONFIG_DDR0";
ddr1.ddrConfigIncludeFileName = "C:\\Users\\11000839\\workspace_v12.4\\sbl_uart_uniflash_am243x-evm_r5fss0-0_nortos_ti-arm-clang\\board_ddrReginit.h";

mmcsd1.$name        = "CONFIG_MMCSD0";
mmcsd1.moduleSelect = "MMC0";
mmcsd1.MMC0.$assign = "MMC0";

uart1.$name        = "CONFIG_UART0";
uart1.intrEnable   = "DISABLE";
uart1.UART.$assign = "USART0";

const udma                         = scripting.addModule("/drivers/udma/udma", {}, false);
const udma1                        = udma.addInstance({}, false);
udma1.$name                        = "CONFIG_UDMA0";
flash1.peripheralDriver.udmaDriver = udma1;

debug_log.enableCssLog      = false;
debug_log.enableLogZoneInfo = true;

mpu_armv71.$name             = "CONFIG_MPU_REGION0";
mpu_armv71.size              = 31;
mpu_armv71.attributes        = "Device";
mpu_armv71.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv71.allowExecute      = false;

mpu_armv72.$name             = "CONFIG_MPU_REGION1";
mpu_armv72.size              = 15;
mpu_armv72.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv73.$name             = "CONFIG_MPU_REGION2";
mpu_armv73.baseAddr          = 0x41010000;
mpu_armv73.size              = 15;
mpu_armv73.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv74.$name             = "CONFIG_MPU_REGION3";
mpu_armv74.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv74.baseAddr          = 0x70000000;
mpu_armv74.size              = 21;

mpu_armv75.$name    = "CONFIG_MPU_REGION4";
mpu_armv75.size     = 31;
mpu_armv75.baseAddr = 0x80000000;

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
flash1.peripheralDriver.OSPI.$suggestSolution      = "OSPI0";
flash1.peripheralDriver.OSPI.CLK.$suggestSolution  = "OSPI0_CLK";
flash1.peripheralDriver.OSPI.CSn0.$suggestSolution = "OSPI0_CSn0";
flash1.peripheralDriver.OSPI.DQS.$suggestSolution  = "OSPI0_DQS";
flash1.peripheralDriver.OSPI.D7.$suggestSolution   = "OSPI0_D7";
flash1.peripheralDriver.OSPI.D6.$suggestSolution   = "OSPI0_D6";
flash1.peripheralDriver.OSPI.D5.$suggestSolution   = "OSPI0_D5";
flash1.peripheralDriver.OSPI.D4.$suggestSolution   = "OSPI0_D4";
flash1.peripheralDriver.OSPI.D3.$suggestSolution   = "OSPI0_D3";
flash1.peripheralDriver.OSPI.D2.$suggestSolution   = "OSPI0_D2";
flash1.peripheralDriver.OSPI.D1.$suggestSolution   = "OSPI0_D1";
flash1.peripheralDriver.OSPI.D0.$suggestSolution   = "OSPI0_D0";
uart1.UART.RXD.$suggestSolution                    = "UART0_RXD";
uart1.UART.TXD.$suggestSolution                    = "UART0_TXD";

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 Florian Otte,

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 Florian Otte,

I would suggest you to use clock <= 50MHz in case of SDR mode. Or you need manually configure the PHY -

Developing a custom flash driver FAQ - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1230063/faq-mcu-plus-sdk-am243x-faq-how-to-debug-develop-migrate-the-flash-driver-for-custom-flash-on-non-ti-evm-ospi-xspi

PHY Tuning on custom algorithms - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1241653/faq-mcu-plus-sdk-am243x-how-to-use-tune-phy-with-mcu_plus_sdk-for-ospi-controller

Currently the PHY is tuned for 8d-8d-8d (and 4s-4d-4d) only. I am really amazed it works with 1s-1s-1s mode.

Another option would be for you to debug the SBL_UART_UNIFLASH for any of the failures in SBL using this FAQ - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1119575/faq-mcu-plus-sdk-am243x-how-to-debug-sbl_qspi-for-am263-and-am273-or-sbl_ospi-for-am243-or-an-application-which-is-booted-via-ospi-qspi-boot

I hope this helps.

Best Regards,
Aakash

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 Florian Otte ,

Florian Otte said:

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