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.

DRA821U: DFU not detected as backup bootmode

Part Number: DRA821U

Hi,

We have developed a new version of our custom board based on the DRA821U.

We are trying to boot the board with eMMC boot0 configured as the primary boot source and DFU as the backup boot source. We would like to use DFU to reach the U-Boot stage and then flash the eMMC.

However, we are still having issues getting DFU to work when booting our custom board. We have tested other boot mode configurations, such as eMMC as primary boot and SD as backup boot, and that setup works correctly. With that configuration, we are able to reach Linux.

We have also verified the boot mode configuration by reading the CTRLMMR_WKUP_BOOTCFG and CTRLMMR_MAIN_BOOTCFG registers from U-Boot, and they contain the expected values.

One relevant change in our custom board is that we modified the MCU_PLL clock configuration because our board uses a 25 MHz clock. Could this clock configuration be related to the issue? Could it affect DFU when it is used as the backup boot mode? We have also configured the bootmode pins accordingly for the 25 MHz clock.

If this clock configuration is not expected to affect DFU, what other points would you recommend checking to help debug the issue?

Thanks.

  • Hi Santiago

    Are you able to flash the bootloader image (tiboot3.bin) at least using DFU boot mode or that also not working ?

    Regards
    Diwakar

  • Hi Santiago,

    Just for clarification,

    Is DFU boot mode working when it is the primary boot mode on the custom board.

    Is DFU boot mode working with the same binaries on TI EVM(DRA821U)?

    Can you share the value of the CTRLMMR_WKUP_BOOTCFG (for MCU_BOOTMODE values) and CTRLMMR_MAIN_BOOTCFG (for BOOTMODE values) when using DFU as the primary boot mode?

    Best Regards

    Gokul Praveen

  • Hi,

    When using DFU as the primary boot mode, we were not able to reach the U-Boot stage, so we could not read the values of CTRLMMR_WKUP_BOOTCFG and CTRLMMR_MAIN_BOOTCFG. Because of this, we continued debugging DFU as a backup boot mode.

    We finally managed to get DFU working as a backup boot mode. We configured SD as the primary boot mode and DFU as the backup boot mode. Booting from SD, we read the following values from U-Boot:

    ##### bootmode dump (SD - DFU) ########
    CTRLMMR_MAIN_BOOTCFG (pag 931 TRM)
    md.l 0x00100034 1
    00100034: 00000043 C...

    CTRLMMR_WKUP_BOOTCFG (pag 360 TRM)
    => md.l 0x43000034 1
    43000034: 00430103

    With these values, we were able to confirm that DFU as backup boot mode was correctly configured.

    After that, we checked the USB_ID resistor. Our board had a pull-down on USB_ID, so we removed it and left USB_ID floating in order to operate as a USB device, as specified in the datasheet, section 6.3 Recommended Operating Conditions.

    After making this change and powering the custom board with both 5 V and 3.3 V, DFU as backup boot mode started working. We also tried powering the board only with 3.3 V, but in that case DFU did not work.

    We then started experimenting with DFU as a flashing method for a second unit.

    We configured the boot mode with eMMC boot0 as the primary boot source and DFU as the backup boot source. Using DFU, we were able to load tiboot3.bin, tispl.bin, and u-boot.img, and successfully reach U-Boot.

    Once in U-Boot, we tried to flash the root filesystem directly, before flashing tiboot3.bin, tispl.bin, and u-boot.img into the eMMC boot0 partition. For this, we used the following commands in U-Boot:

    setenv dfu_alt_info emmc raw 0 0

    dfu 0 mmc 0

    Later in the host:

    sudo dfu-util -a emmc -D emmc-image.rootfs.wic

    The transfer started and initially seemed to work correctly, but at around 20% it appeared to crash. DFU was interrupted and dfu-util reported a transmission failure..

    After rebooting the board, we could no longer enter DFU as the backup boot mode. Since we had not flashed the bootloader images into eMMC boot0, we expected the ROM bootloader to fail on the primary boot source and then fall back to the backup boot source, which is DFU.

    Could we have corrupted the eMMC in a way that prevents the device from falling back to DFU, even though we only attempted to flash the root filesystem and had not yet flashed the bootloader to boot0?

    Also, is there any timeout or failure condition in the ROM boot flow that determines when the device gives up trying to boot from eMMC boot0 and jumps to the backup boot mode? For example, if tiboot3.bin is not found or cannot be loaded correctly, should the device always fall back to DFU?

    Thanks for your support.

  • Hi Santiago,

    Could we have corrupted the eMMC in a way that prevents the device from falling back to DFU, even though we only attempted to flash the root filesystem and had not yet flashed the bootloader to boot0

    Yes, the eMMC is corrupted I believe. Can you boot upto Uboot using SD card and try the below commands which will flash everyting to eMMC through DFU .

    Can you try the below steps to flash to eMMC from UBOOT using the below reference: section 3.3 Generating the eMMC tisdk-tiny-image.img and section 5.1.3 dfu-util

    TDA4 Flashing Techniques

    Best Regards

    Gokul Praveen

  • Hi Gokul,

    Sorry for the delayed response.

    We finally managed to get the eMMC working. At the end, the eMMC was not corrupted.

    The issue was related to our USB cable, which seemed to have intermittent connection problems. Because of that, DFU was not being detected correctly, but it was not caused by eMMC corruption.

    After replacing the USB cable, we were able to flash both the eMMC and the eMMC boot0 partition via DFU from U-Boot without any issues.

    Thank you very much for your attention and for your support throughout the different stages.

    Best regards,
    Santi

  • HI Santiago,

    Glad to hear that the issue is resolved.

    Best REgards

    Gokul Praveen