Highlighted
Contributor - Level 2

Debugging a bricked Ditto X4

Disclaimer
I am in no way affiliated with TC Electronics or anyone/anything to do with them. I'm just an annoyed customer with a bricked Ditto X4 and some technical know-how.

Edit: The Solution!
This issue is now resolved, so instead of having you read pages of write-up, I'll condense the solution for you here. If your pedal won't start up, showing either a single red LED above the LOOP1 button or all orange lights, this will get you back in working condition.

Note #1: This will erase any loops you have saved! If you want your data you'll need to copy it off the SD card first and copy it back on once you're finished re-imaging the card.

Note #2: This will void your warranty! If your pedal is still under warranty I suggest you explore warranty options first, DIY last. Having got that out of the way...


[list=1]
  • Make sure you have an SD card reader/writer on your computer. For example: https://www.amazon.com/Anker-Portable-Reader-RS-MMC-Micro/dp/B006T9B6R2/ref=sr_1_4?s=pc&ie=UTF8&qid=...

  • Download Etcher: https://www.balena.io/etcher/

  • Download the X4 SD card image (v1.3.00 build 89): https://mega.nz/#!NMdRiAIY!GtrYevDAjHzPgiYAiwUaj_X9qjVVJ-HF3ZX1MP1mrLo

  • Remove the SD card from your X4 by removing the bottom of the X4, slide the SD card clip to the side to release the catch, then lift the card out. You'll need a torx bit for your screwdriver in order to open the pedal.

  • Put the SD card into the reader/writer.

  • Run Etcher and select the X4 image you downloaded earlier.

  • Write it to the SD card using Etcher - it's self-explanatory.

  • Once it's finished, put the SD card back into the pedal, put the back on, and power it up to test.

  • Apply the latest firmware update from TC.

  • Play music!




  • Forum user fzzbx said that Etcher didn't work for him, but Win32DiskImager did, so here's his instructions for making it work:

    fzzbx wrote:

    My solution was to use a program called Win32DiskImager instead.

    https://sourceforge.net/projects/win32diskimager/

    I renamed the .bin file provided by phantom to a .img file, and used this program to image the SD card.

    It worked on the first try!


    fzzbx also makes a good point that your SD card could have gone bad, which means a new image won't work and will probably fail to write to the card - you may also need a new SD card. This one would be fine: https://www.amazon.com/SanDisk%C2%AE-microSDHCTM-8GB-Memory-Card/dp/B0012Y2LLE/ref=sr_1_4?ie=UTF8&qi...


    Original post continues here.



    Symptoms
    When power is applied, all the lights come on in red and green (people call it orange?) A few seconds later all the LEDs go off and the single solid red LED at LOOP1 comes on and stays on. It doesn't respond to button presses.

    If I put a blank SD-card in the X4 instead of the one it came with, it never boots past all of the lights coming on - it doesn't get as far as turning on the LOOP1 red LED.

    Boot Mode
    You've all read the instructions to get it into boot mode. They don't work for this X4. Powering on with the LOOP1 button down does nothing.

    Firmware Update to 1.3.00r89
    It fails. The X4 is detected by the Windows Ditto X4 updater as a "Microsoft Wavetable GS Synth", which I believe is a MIDI device. I guess that means it's not in boot mode, but I tried installing the update regardless. It gets all the way to 100%, then stalls and does nothing. No lights change on the X4, the updater program just sits at 100%.

    TC's Technical Support
    Turns out they're neither technical nor supportive. I filed a ticket with a detailed bug report of the problem, but they just referred me to a repair shop in Texas and closed the support ticket. I tried repeatedly to get more technical information about debugging the issue, but didn't get anywhere. Like most of the TC support encounters I've read about, it wasn't helpful.

    DIY
    So here we are. A bricked X4 and a small workshop full of electronic toys. Here's tonight's efforts:


    (https://i.imgur.com/8c61Cgf.jpg)

    Architecture
    It turns out to be powered by a small NXP i.MX283 ARM9 system-on-chip. There's an ATMEL ATtiny48 microcontroller, too. The ISP header is exposed but unpopulated.

    My guess (to be confirmed) is that IC1 (64k serial EEPROM) contains a boot loader that's executed by the MX283. The boot loader (U-Boot) presumably boots a Linux kernel off the SD-card, which loads the pedal's control software. This is speculation at present.

    I don't know what the ATtiny is doing. I attached an ISP programmer to it (my trusty TNM5000):



    It detected the ATtiny without any problem:



    I checked the fuses on the ATtiny and it's been locked, making it impossible (ok, infeasible) to dump the firmware out of it:



    There may be an opportunity to use the bootloader to dump the ATtiny ROM, but for now that's out of scope for what I need in order to diagnose the problem.

    Debugging Interfaces
    There are at least 3 UART debug interfaces onboard.
    J15 (not marked on the image above) is a read-only serial debug log at 115200 8N1
    J11 is labeled "debug comm port". I haven't connected to it yet.
    J17 is a read-write serial console attached to the 1st-stage bootloader, U-Boot. 115200 8N1.

    J17 Serial Console
    I used a Sparkfun "beefy" serial/USB adaptor (https://www.sparkfun.com/products/13746) to hookup the RX, TX and GND pins at J17. This is what I get at power on:

    [code]
    U-Boot 2013.01 (Nov 16 2015 - 17:20:34)

    CPU: Freescale i.MX28 rev1.2 at 454 MHz
    BOOT: I2C #0, master, 3V3
    I2C: ready
    DRAM: 128 MiB
    MMC: MXS MMC: 0
    *** Warning - bad CRC, using default environment

    In: serial
    Out: serial
    Err: serial
    Net: FEC0 [PRIME]
    Warning: FEC0 using MAC address from net device
    , FEC1
    Warning: FEC1 using MAC address from net device

    Hit any key to stop autoboot: 0
    1024 .
    1024 ..
    12288 lost+found
    ** File not found /update.tar **
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 1073750502
    ext4fs_devread read outside partition 8520198
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 8520198
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    internal error
    TCE-X4 U-Boot >
    [/code]

    The environment shows more information about what's happening at boot time:


    boot_recovery=if ext2ls mmc 0:${partition_recovery}; then if $update_present; then if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.update; then vl3lcd ${loadaddr} ${filesize}; fi; else if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.recovery; then vl3lcd ${loadaddr} ${filesize}; fi; fi; mw.l $loadaddr 0; if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/uImage; then if iminfo $loadaddr; then setenv env_state ${env_state},STATE_BOOT_FROM_RECOVERY; setenv partition ${partition_recovery}; run bootargs_ext; bootm ${loadaddr}; exit; fi; else setenv env_error ${env_error},ERROR_RECOVERY_UIMAGE; fi; else setenv env_error ${env_error},ERROR_FS_MOUNT_RECOVERY; fi; echo 'internal error'; exit;
    boot_working=if ext2ls mmc 0:${partition_working}; then if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.working; then vl3lcd ${loadaddr} ${filesize}; fi; mw.l $loadaddr 0; if ext2load mmc 0:${partition_working} ${loadaddr} /boot/uImage; then if iminfo $loadaddr; then setenv env_state ${env_state},STATE_BOOT_FROM_WORKING; setenv partition ${partition_working}; run bootargs_ext; bootm ${loadaddr}; exit; else setenv env_error ${env_error},ERROR_WORKING_UIMAGE; fi; else setenv env_error ${env_error},ERROR_WORKING_UIMAGE; fi; else setenv env_error ${env_error},ERROR_FS_MOUNT_WORKING; fi; x4led 0x80;run boot_recovery;
    bootargs_ext=setenv bootargs console=ttyAM0,${baudrate}n8 rootfstype=ext4 root=/dev/mmcblk0p${partition} rw rootwait ssp1 env_error=${env_error} env_state=${env_state}
    bootcmd=run bootcmd_vl3
    bootcmd_vl3=run init_scripts; run set_contrast; run mount_scratch; run test_recovery_button; run test_pot_calib_button; run test_update_present
    bootdelay=1
    bootfile=uImage
    env_error=,ERROR_FS_MOUNT_WORKING,ERROR_RECOVERY_UIMAGE
    eth1addr=00:04:00:00:00:01
    ethact=FEC0
    ethaddr=00:04:00:00:00:00
    ethprime=FEC0
    init_scripts=setenv env_error; setenv env_state; setenv linuxmode; setenv update_present false;
    loadaddr=0x42000000
    mount_scratch=if ext2ls mmc 0:${partition_scratch}; then true; else setenv env_error ${env_error},ERROR_FS_MOUNT_SCRATCH; false; fi
    partition_boot=1
    partition_extended=4
    partition_recovery=2
    partition_scratch=5
    partition_user=7
    partition_working=3
    set_contrast=mw.l 80040088 20000000; mw.l 80064008 c0000000; mw.l 80064010 00ff00e3; mw.l 80064020 001e00ff; mw.l 80064004 00000001;
    stderr=serial
    stdin=serial
    stdout=serial



    LED control
    From the environment we can see that the boot loader is using the command "x4led" to change the color of the LEDs in response to different boot events. For example, at the end of the "boot_working" script in the environment we can see the command "x4led 0x80", which turns the LOOP1 LED red. That's exactly the failure I'm seeing!

    I played with it a bit. Here's "x4led 0xfc" (the LEDs look green but they're actually orange):



    And here's "x4led 0x66":



    Partitions
    This is interesting:


    partition_boot=1
    partition_extended=4
    partition_recovery=2
    partition_scratch=5
    partition_user=7
    partition_working=3


    The boot loader expects to find the partition layout of the SD-card as shown. In Linux parlance, the "working" partition would be /dev/mmcblk0p3 and the "recovery" partition would be /dev/mmcblk0p2.

    Boot Failures
    Here's what happens when we try to run the "boot_working" script:


    TCE-X4 U-Boot > run boot_working
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 8389126
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    internal error
    TCE-X4 U-Boot >


    Here's the definition of "boot_working" made pretty:


    if ext2ls mmc 0:${partition_working}; then
    if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.working; then
    vl3lcd ${loadaddr} ${filesize}
    fi

    mw.l $loadaddr 0

    if ext2load mmc 0:${partition_working} ${loadaddr} /boot/uImage; then
    if iminfo $loadaddr; then
    setenv env_state ${env_state},STATE_BOOT_FROM_WORKING
    setenv partition ${partition_working}
    run bootargs_ext
    bootm ${loadaddr}
    exit
    else
    setenv env_error ${env_error},ERROR_WORKING_UIMAGE
    fi
    else
    setenv env_error ${env_error},ERROR_WORKING_UIMAGE
    fi
    else
    setenv env_error ${env_error},ERROR_FS_MOUNT_WORKING
    fi

    x4led 0x80
    run boot_recovery


    So we can see that U-Boot starts, runs "boot_working", fails, sets the LOOP1 red LED, then calls "run boot_recovery", which also fails, causing U-Boot to drop to a command-line. We can also see the individual errors happening for first boot_working, then boot_recovery. Here's the error from boot_working:


    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 8389126


    And here's the error from boot_recovery:

    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    internal error


    Diagnosis
    It looks like there's nothing wrong with the pedal, which is great news. Instead, the problem seems to be that it can't boot from the SD-card due to errors mounting the working partition (mmcblk0p3) and the recovery partition (mmcblk0p2).

    Time to take a peek at that SD-card. To be continued.
    Tags (1)
    phantomraspberr Contributor - Level 2 2018-12-04

    2018-12-04

    Debugging a bricked Ditto X4

    Disclaimer
    I am in no way affiliated with TC Electronics or anyone/anything to do with them. I'm just an annoyed customer with a bricked Ditto X4 and some technical know-how.

    Edit: The Solution!
    This issue is now resolved, so instead of having you read pages of write-up, I'll condense the solution for you here. If your pedal won't start up, showing either a single red LED above the LOOP1 button or all orange lights, this will get you back in working condition.

    Note #1: This will erase any loops you have saved! If you want your data you'll need to copy it off the SD card first and copy it back on once you're finished re-imaging the card.

    Note #2: This will void your warranty! If your pedal is still under warranty I suggest you explore warranty options first, DIY last. Having got that out of the way...


    [list=1]

  • Make sure you have an SD card reader/writer on your computer. For example: https://www.amazon.com/Anker-Portable-Reader-RS-MMC-Micro/dp/B006T9B6R2/ref=sr_1_4?s=pc&ie=UTF8&qid=1544220198&sr=1-4&keywords=sd+card+reader

  • Download Etcher: https://www.balena.io/etcher/

  • Download the X4 SD card image (v1.3.00 build 89): https://mega.nz/#!NMdRiAIY!GtrYevDAjHzPgiYAiwUaj_X9qjVVJ-HF3ZX1MP1mrLo

  • Remove the SD card from your X4 by removing the bottom of the X4, slide the SD card clip to the side to release the catch, then lift the card out. You'll need a torx bit for your screwdriver in order to open the pedal.

  • Put the SD card into the reader/writer.

  • Run Etcher and select the X4 image you downloaded earlier.

  • Write it to the SD card using Etcher - it's self-explanatory.

  • Once it's finished, put the SD card back into the pedal, put the back on, and power it up to test.

  • Apply the latest firmware update from TC.

  • Play music!




  • Forum user fzzbx said that Etcher didn't work for him, but Win32DiskImager did, so here's his instructions for making it work:

    fzzbx wrote:

    My solution was to use a program called Win32DiskImager instead.

    https://sourceforge.net/projects/win32diskimager/

    I renamed the .bin file provided by phantom to a .img file, and used this program to image the SD card.

    It worked on the first try!


    fzzbx also makes a good point that your SD card could have gone bad, which means a new image won't work and will probably fail to write to the card - you may also need a new SD card. This one would be fine: https://www.amazon.com/SanDisk%C2%AE-microSDHCTM-8GB-Memory-Card/dp/B0012Y2LLE/ref=sr_1_4?ie=UTF8&qid=1544302078&sr=8-4&keywords=8gb+micro+sd+card


    Original post continues here.



    Symptoms
    When power is applied, all the lights come on in red and green (people call it orange?) A few seconds later all the LEDs go off and the single solid red LED at LOOP1 comes on and stays on. It doesn't respond to button presses.

    If I put a blank SD-card in the X4 instead of the one it came with, it never boots past all of the lights coming on - it doesn't get as far as turning on the LOOP1 red LED.

    Boot Mode
    You've all read the instructions to get it into boot mode. They don't work for this X4. Powering on with the LOOP1 button down does nothing.

    Firmware Update to 1.3.00r89
    It fails. The X4 is detected by the Windows Ditto X4 updater as a "Microsoft Wavetable GS Synth", which I believe is a MIDI device. I guess that means it's not in boot mode, but I tried installing the update regardless. It gets all the way to 100%, then stalls and does nothing. No lights change on the X4, the updater program just sits at 100%.

    TC's Technical Support
    Turns out they're neither technical nor supportive. I filed a ticket with a detailed bug report of the problem, but they just referred me to a repair shop in Texas and closed the support ticket. I tried repeatedly to get more technical information about debugging the issue, but didn't get anywhere. Like most of the TC support encounters I've read about, it wasn't helpful.

    DIY
    So here we are. A bricked X4 and a small workshop full of electronic toys. Here's tonight's efforts:


    (https://i.imgur.com/8c61Cgf.jpg)

    Architecture
    It turns out to be powered by a small NXP i.MX283 ARM9 system-on-chip. There's an ATMEL ATtiny48 microcontroller, too. The ISP header is exposed but unpopulated.

    My guess (to be confirmed) is that IC1 (64k serial EEPROM) contains a boot loader that's executed by the MX283. The boot loader (U-Boot) presumably boots a Linux kernel off the SD-card, which loads the pedal's control software. This is speculation at present.

    I don't know what the ATtiny is doing. I attached an ISP programmer to it (my trusty TNM5000):



    It detected the ATtiny without any problem:



    I checked the fuses on the ATtiny and it's been locked, making it impossible (ok, infeasible) to dump the firmware out of it:



    There may be an opportunity to use the bootloader to dump the ATtiny ROM, but for now that's out of scope for what I need in order to diagnose the problem.

    Debugging Interfaces
    There are at least 3 UART debug interfaces onboard.
    J15 (not marked on the image above) is a read-only serial debug log at 115200 8N1
    J11 is labeled "debug comm port". I haven't connected to it yet.
    J17 is a read-write serial console attached to the 1st-stage bootloader, U-Boot. 115200 8N1.

    J17 Serial Console
    I used a Sparkfun "beefy" serial/USB adaptor (https://www.sparkfun.com/products/13746) to hookup the RX, TX and GND pins at J17. This is what I get at power on:

    [code]
    U-Boot 2013.01 (Nov 16 2015 - 17:20:34)

    CPU: Freescale i.MX28 rev1.2 at 454 MHz
    BOOT: I2C #0, master, 3V3
    I2C: ready
    DRAM: 128 MiB
    MMC: MXS MMC: 0
    *** Warning - bad CRC, using default environment

    In: serial
    Out: serial
    Err: serial
    Net: FEC0 [PRIME]
    Warning: FEC0 using MAC address from net device
    , FEC1
    Warning: FEC1 using MAC address from net device

    Hit any key to stop autoboot: 0
    1024 .
    1024 ..
    12288 lost+found
    ** File not found /update.tar **
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 1073750502
    ext4fs_devread read outside partition 8520198
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 8520198
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    internal error
    TCE-X4 U-Boot >
    [/code]

    The environment shows more information about what's happening at boot time:


    boot_recovery=if ext2ls mmc 0:${partition_recovery}; then if $update_present; then if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.update; then vl3lcd ${loadaddr} ${filesize}; fi; else if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.recovery; then vl3lcd ${loadaddr} ${filesize}; fi; fi; mw.l $loadaddr 0; if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/uImage; then if iminfo $loadaddr; then setenv env_state ${env_state},STATE_BOOT_FROM_RECOVERY; setenv partition ${partition_recovery}; run bootargs_ext; bootm ${loadaddr}; exit; fi; else setenv env_error ${env_error},ERROR_RECOVERY_UIMAGE; fi; else setenv env_error ${env_error},ERROR_FS_MOUNT_RECOVERY; fi; echo 'internal error'; exit;
    boot_working=if ext2ls mmc 0:${partition_working}; then if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.working; then vl3lcd ${loadaddr} ${filesize}; fi; mw.l $loadaddr 0; if ext2load mmc 0:${partition_working} ${loadaddr} /boot/uImage; then if iminfo $loadaddr; then setenv env_state ${env_state},STATE_BOOT_FROM_WORKING; setenv partition ${partition_working}; run bootargs_ext; bootm ${loadaddr}; exit; else setenv env_error ${env_error},ERROR_WORKING_UIMAGE; fi; else setenv env_error ${env_error},ERROR_WORKING_UIMAGE; fi; else setenv env_error ${env_error},ERROR_FS_MOUNT_WORKING; fi; x4led 0x80;run boot_recovery;
    bootargs_ext=setenv bootargs console=ttyAM0,${baudrate}n8 rootfstype=ext4 root=/dev/mmcblk0p${partition} rw rootwait ssp1 env_error=${env_error} env_state=${env_state}
    bootcmd=run bootcmd_vl3
    bootcmd_vl3=run init_scripts; run set_contrast; run mount_scratch; run test_recovery_button; run test_pot_calib_button; run test_update_present
    bootdelay=1
    bootfile=uImage
    env_error=,ERROR_FS_MOUNT_WORKING,ERROR_RECOVERY_UIMAGE
    eth1addr=00:04:00:00:00:01
    ethact=FEC0
    ethaddr=00:04:00:00:00:00
    ethprime=FEC0
    init_scripts=setenv env_error; setenv env_state; setenv linuxmode; setenv update_present false;
    loadaddr=0x42000000
    mount_scratch=if ext2ls mmc 0:${partition_scratch}; then true; else setenv env_error ${env_error},ERROR_FS_MOUNT_SCRATCH; false; fi
    partition_boot=1
    partition_extended=4
    partition_recovery=2
    partition_scratch=5
    partition_user=7
    partition_working=3
    set_contrast=mw.l 80040088 20000000; mw.l 80064008 c0000000; mw.l 80064010 00ff00e3; mw.l 80064020 001e00ff; mw.l 80064004 00000001;
    stderr=serial
    stdin=serial
    stdout=serial



    LED control
    From the environment we can see that the boot loader is using the command "x4led" to change the color of the LEDs in response to different boot events. For example, at the end of the "boot_working" script in the environment we can see the command "x4led 0x80", which turns the LOOP1 LED red. That's exactly the failure I'm seeing!

    I played with it a bit. Here's "x4led 0xfc" (the LEDs look green but they're actually orange):



    And here's "x4led 0x66":



    Partitions
    This is interesting:


    partition_boot=1
    partition_extended=4
    partition_recovery=2
    partition_scratch=5
    partition_user=7
    partition_working=3


    The boot loader expects to find the partition layout of the SD-card as shown. In Linux parlance, the "working" partition would be /dev/mmcblk0p3 and the "recovery" partition would be /dev/mmcblk0p2.

    Boot Failures
    Here's what happens when we try to run the "boot_working" script:


    TCE-X4 U-Boot > run boot_working
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 8389126
    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    internal error
    TCE-X4 U-Boot >


    Here's the definition of "boot_working" made pretty:


    if ext2ls mmc 0:${partition_working}; then
    if ext2load mmc 0:${partition_recovery} ${loadaddr} /boot/splash.working; then
    vl3lcd ${loadaddr} ${filesize}
    fi

    mw.l $loadaddr 0

    if ext2load mmc 0:${partition_working} ${loadaddr} /boot/uImage; then
    if iminfo $loadaddr; then
    setenv env_state ${env_state},STATE_BOOT_FROM_WORKING
    setenv partition ${partition_working}
    run bootargs_ext
    bootm ${loadaddr}
    exit
    else
    setenv env_error ${env_error},ERROR_WORKING_UIMAGE
    fi
    else
    setenv env_error ${env_error},ERROR_WORKING_UIMAGE
    fi
    else
    setenv env_error ${env_error},ERROR_FS_MOUNT_WORKING
    fi

    x4led 0x80
    run boot_recovery


    So we can see that U-Boot starts, runs "boot_working", fails, sets the LOOP1 red LED, then calls "run boot_recovery", which also fails, causing U-Boot to drop to a command-line. We can also see the individual errors happening for first boot_working, then boot_recovery. Here's the error from boot_working:


    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    ext4fs_devread read outside partition 8389126


    And here's the error from boot_recovery:

    Failed to mount ext2 filesystem...
    ** Unrecognized filesystem type **
    internal error


    Diagnosis
    It looks like there's nothing wrong with the pedal, which is great news. Instead, the problem seems to be that it can't boot from the SD-card due to errors mounting the working partition (mmcblk0p3) and the recovery partition (mmcblk0p2).

    Time to take a peek at that SD-card. To be continued.

    • 0 Kudos
    • 27 Replies
    • Reply
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    Great work. I’m subscribing to see what happens!
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    The SD-card is detected by Linux like so:

    [code]
    [92496.845377] usb 4-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
    [92496.877984] usb 4-1: New USB device found, idVendor=8564, idProduct=4000, bcdDevice= 0.26
    [92496.877986] usb 4-1: New USB device strings: Mfr=3, Product=4, SerialNumber=5
    [92496.877987] usb 4-1: Product: Transcend
    [92496.877988] usb 4-1: Manufacturer: TS-RDF8
    [92496.877989] usb 4-1: SerialNumber: 000000082
    [92497.022488] usb-storage 4-1:1.0: USB Mass Storage device detected
    [92497.023537] scsi host3: usb-storage 4-1:1.0
    [92497.044316] usbcore: registered new interface driver usb-storage
    [92497.049897] usbcore: registered new interface driver uas
    [92498.085494] scsi 3:0:0:0: Direct-Access Generic STORAGE DEVICE TS26 PQ: 0 ANSI: 6
    [92498.099153] scsi 3:0:0:1: Direct-Access Generic STORAGE DEVICE TS26 PQ: 0 ANSI: 6
    [92498.103213] scsi 3:0:0:2: Direct-Access Generic STORAGE DEVICE TS26 PQ: 0 ANSI: 6
    [92498.128422] sd 3:0:0:0: Attached scsi generic sg2 type 0
    [92498.136117] sd 3:0:0:1: Attached scsi generic sg3 type 0
    [92498.139803] sd 3:0:0:2: Attached scsi generic sg4 type 0
    [92498.346645] sd 3:0:0:0: [sdb] Attached SCSI removable disk
    [92498.349032] sd 3:0:0:1: [sdc] 7774208 512-byte logical blocks: (3.98 GB/3.71 GiB)
    [92498.354951] sd 3:0:0:1: [sdc] Write Protect is off
    [92498.354953] sd 3:0:0:1: [sdc] Mode Sense: 21 00 00 00
    [92498.367678] sd 3:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
    [92498.369886] sd 3:0:0:2: [sdd] Attached SCSI removable disk
    [92498.429390] sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 >
    [92498.629562] sd 3:0:0:1: [sdc] Attached SCSI removable disk
    [92503.317795] EXT4-fs (sdc2): ext4_check_descriptors: Inode bitmap for group 0 not in group (block 75628883)!
    [92503.317799] EXT4-fs (sdc2): group descriptors corrupted!
    [92503.345184] EXT4-fs (sdc5): warning: maximal mount count reached, running e2fsck is recommended
    [92503.361324] EXT4-fs (sdc5): mounted filesystem with ordered data mode. Opts: (null)
    [/code]

    Fdisk:

    root@kali:~# fdisk -l /dev/sdc
    Disk /dev/sdc: 3.7 GiB, 3980394496 bytes, 7774208 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x00000000

    Device Boot Start End Sectors Size Id Type
    /dev/sdc1 8 62567 62560 30.6M 53 OnTrack DM6 Aux3
    /dev/sdc2 62568 562607 500040 244.2M 83 Linux
    /dev/sdc3 562608 812663 250056 122.1M 83 Linux
    /dev/sdc4 812664 7774199 6961536 3.3G 5 Extended
    /dev/sdc5 812672 1312703 500032 244.2M 83 Linux
    /dev/sdc6 1312712 2312783 1000072 488.3M b W95 FAT32
    /dev/sdc7 2312824 7774231 5461408 2.6G 83 Linux


    I've seen reports of folks seeing a FAT32 partition on X4s, and here we wee a W95 FAT extended partition amongst a bunch of Linux partitions and whatever an OnTrack DM6 Aux3 is.

    The partitions I'm interested in are 2 and 3, the working and recovery partitions. But first: backup!


    root@kali:~# dd if=/dev/sdc of=x4.bin bs=1M
    3796+0 records in
    3796+0 records out
    3980394496 bytes (4.0 GB, 3.7 GiB) copied, 162.108 s, 24.6 MB/s


    Safe to play. Did anything automatically mount?


    root@kali:~# mount | grep sdc
    /dev/sdc5 on /media/root/33f500a6-1dd2-11b2-b471-5d8ba6ea4224 type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)


    Partition 5, the "scratch" partition, is mounted. Anything on it?


    root@kali:~# find /media/root/33f500a6-1dd2-11b2-b471-5d8ba6ea4224/
    /media/root/33f500a6-1dd2-11b2-b471-5d8ba6ea4224/
    /media/root/33f500a6-1dd2-11b2-b471-5d8ba6ea4224/lost+found


    Nothing.

    Partitions 2 and 3 didn't mount, which matches the behavior of the boot loader. Running e2fsck first caused an error:

    root@kali:~# fsck /dev/sdc3
    fsck from util-linux 2.32.1
    e2fsck 1.44.4 (18-Aug-2018)
    /dev/sdc3 has unsupported feature(s): FEATURE_C19 FEATURE_C21 FEATURE_I28 FEATURE_R18 FEATURE_R30
    e2fsck: Get a newer version of e2fsck!


    I built the latest version from github (https://github.com/tytso/e2fsprogs) and it worked fine. There were a bajillion errors on partition 2 and it kept on "fixing" until the partition was irrecoverable:


    ...
    Restarting e2fsck from the beginning...
    ext2fs_open2: The ext2 superblock is corrupt
    ./e2fsck: Superblock invalid, trying backup blocks...
    ./e2fsck: The ext2 superblock is corrupt while trying to open /dev/sdc2
    ./e2fsck: Trying to load superblock despite errors...
    ext2fs_open2: The ext2 superblock is corrupt
    ./e2fsck: Superblock invalid, trying backup blocks...
    Corruption found in superblock. (inodes_count = 0).

    The superblock could not be read or does not describe a valid ext2/ext3/ext4
    filesystem. If the device is valid and it really contains an ext2/ext3/ext4
    filesystem (and not swap or ufs or something else), then the superblock
    is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193
    or
    e2fsck -b 32768


    /dev/sdc2: ***** FILE SYSTEM WAS MODIFIED *****
    root@kali:~/e2fsprogs/e2fsck#
    root@kali:~/e2fsprogs/e2fsck# mount /dev/sdc2 /mnt
    mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdc2, missing codepage or helper program, or other error.


    Looks like the partitions are hosed whether I try to fix them or not.

    Is there anyone who'd be up for taking an image of their SD-card? I'd like to try writing a known-good image to a new SD-card to see if it will boot in my X4. I can walk you through the process if you like.

    Thanks!
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    By jumpering J25 "boot select" you can force the pedal into boot mode, where it will be detected by the Ditto X4 1.3.00r89 updater program. Mine is still being reported as follows:



    I'm pretty sure that should say "Ditto X4"!
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    Is there anyone willing and able to take an image of their SD-card for me to try in my X4?
    Contributor - Level 1

    Re: Debugging a bricked Ditto X4

    phantomraspberryblower wrote:
    Is there anyone willing and able to take an image of their SD-card for me to try in my X4?


    I would also like to see if my SD-card is working properly. None of my computers recognizes my DittoX4 as a USB-device, so the firmware update is impossible to do.

    I took the SD-card out and tried to read it. Right now my Windows recognizes the card as six different partitions and only one of them is readable. The readable partition is named DittoX4 and is in FAT32. The other five are in unknown file system format and not readable.

    The DittoX4 partition contains two folders "TRACK1" & "TRACK2" and a about.txt -file, which contains the firmware version "Version: 1.0.00 BUILD 35"

    If this is normal, then the fault is somewhere else.
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    silvenin wrote:
    phantomraspberryblower wrote:
    Is there anyone willing and able to take an image of their SD-card for me to try in my X4?


    I would also like to see if my SD-card is working properly. None of my computers recognizes my DittoX4 as a USB-device, so the firmware update is impossible to do.

    I took the SD-card out and tried to read it. Right now my Windows recognizes the card as six different partitions and only one of them is readable. The readable partition is named DittoX4 and is in FAT32. The other five are in unknown file system format and not readable.

    The DittoX4 partition contains two folders "TRACK1" & "TRACK2" and a about.txt -file, which contains the firmware version "Version: 1.0.00 BUILD 35"


    The other partitions are mostly Linux partitions - the Ditto X4 runs Linux, possibly SuSE based on some data I've seen.


    Device Boot Start End Sectors Size Id Type
    /dev/sdc1 8 62567 62560 30.6M 53 OnTrack DM6 Aux3
    /dev/sdc2 62568 562607 500040 244.2M 83 Linux
    /dev/sdc3 562608 812663 250056 122.1M 83 Linux
    /dev/sdc4 812664 7774199 6961536 3.3G 5 Extended
    /dev/sdc5 812672 1312703 500032 244.2M 83 Linux
    /dev/sdc6 1312712 2312783 1000072 488.3M b W95 FAT32
    /dev/sdc7 2312824 7774231 5461408 2.6G 83 Linux


    silvenin wrote:

    If this is normal, then the fault is somewhere else.


    Not necessarily. The FAT32 (windows) partition on my SD-card is fine, but Linux partitions 2 and 3 are not. These are the partitions that hold the Linux systems and Ditto X4 software responsible for boot recovery (partition 2) and the working pedal (partition 3).

    If, like mine, your 2nd and 3rd partitions are corrupt while your 6th partition (FAT32) is not, it could explain why your pedal is a brick.

    The more I look at this, the more I'm starting to think corrupt Linux partitions are responsible for much bricking. I'll give you an example: ext4 partitions maintain a "mount count". if the mount count hits 32 without a filesystem integrity check being run, the partition will fail to mount. Insta-brick. If it happens only to partition 3 then it's still possible to boot from partition #2 (recovery) to re-flash the pedal (working partition #3), which would reset the mount count and restore the pedal's functionality. If partition #2 hits a 32 mount count without being checked, it would become impossible to enter recovery mode.

    When people send their pedals off for repair, I'd wager that either the SD-card or the entire PCB is replaced; this puts a fresh, non-corrupt set of Linux partitions back in the pedal, and voila! It's not bricked any more.

    Short version: if we had a master Ditto software image from which we could re-image the entire SD card, I bet a lot of pedals would magically become unbricked.
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    I retract my comment about TC's support being unsupportive.

    I'd like to give props to the support guy who took my case initially. He has stayed in contact and genuinely appears to be trying to help. I won't use his real name, I'll refer to him simply as the dude.

    The dude is reaching out to a service tech about my request for a new SD-card or an image suitable for dd-ing onto a new SD-card. Fingers crossed, let's see what happens!

    Edit: I'll add that I've reached out to the repair shop in Texas to whom I was initially referred by the dude. Their service tech is also getting in touch with TC to see if he can source an SD-card or an image.
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    Sadly TC Electronic support have stopped responding to my emails.
    The repair shop never got back to me and don't pick up the phone.
    Nobody on this forum has stepped up with an offer of copying their SD card.

    Back to DIY! There's a couple of options at this point:

    [list=*]
  • Reverse-engineer the updater program to extract "update.tar", grab the root filesystem image, and install it manually.

  • Go to a Guitar Center, buy a new Ditto X4, take a copy of the SD card, and return the X4 to Guitar Center.



  • Obviously option #2 is a little unethical, so we'll leave it as a last resort option. It's a sure-fire way to get a working image, so I'm not ruling out entirely.

    Option #1 is preferable to my DIY mindset. So... watch this space.
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    The Ditto X4 updater comes as an all-in-one executable file on both Mac and Windows. In this example I'm working with version 1.3.00r91beta. We can see in a hex editor that there's a TAR archive embedded in the updater. It contains two files: update.sh and rootfs.tar.gz:

    update.sh:

    (https://i.imgur.com/yUOA4ZK.png)

    rootfs.tar.gz:

    (https://i.imgur.com/MtqToSr.png)

    The first thing I noticed was that the data for update.sh seems to have extra NULL bytes dotted throughout it. Is this a means of obfuscation to thwart people like me? I extracted update.sh and removed the NULLs like so:


    $ dd if=dittox4_RC_1.3.00_build_91.exe bs=1 skip=5341523 count=972 of=update.sh
    972+0 records in
    972+0 records out
    972 bytes transferred in 0.010591 secs (91776 bytes/sec)
    $ tr -d '\000' < update.sh


    Here's the NULL-less version:

    [code]
    #!/bin/sh

    echo "Starting firmware update on working partition..."

    # Test the integrity of the update file
    tar -tvzf rootfs.tar.gz >/dev/null
    if [ $? -eq 0 ]; then

    # reformat the working partition
    umount /mnt/mmcblk0p3
    mkfs.ext4 /dev/mmcblk0p3
    mount -t ext4 /dev/mmcblk0p3 /mnt/mmcblk0p3

    # if the format worked, unpack to the now empty working partition
    if [ $? -eq 0 ]; then
    tar -vzxf rootfs.tar.gz -C /mnt/mmcblk0p3
    if [ $? -ne 0 ]; then
    export ENV_ERROR=${ENV_ERROR},ERROR_UPDATE_CORRUPT
    else
    # Everything went okay...
    sync
    export ENV_STATE=${ENV_STATE},STATE_UPDATE_COMPLETE
    export ENV_INFO=${ENV_INFO},INFO_UPDATE_COMPLETE
    fi;
    else
    export ENV_ERROR=${ENV_ERROR},ERROR_EXT_FORMAT_WORKING
    fi;
    else
    export ENV_ERROR=${ENV_ERROR},ERROR_UPDATE_CORRUPT
    fi;

    echo "Firmware update complete: ${ENV_ERROR} ${ENV_INFO}"
    [/code]

    Awesome! We can see that the process blows away the working partition, re-creates it, then un-tars rootfs.tar.gz into it. We should be able to replicate that process manually.