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
    Highlighted
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    Moving onto rootfs.tar.gz. This one is trickier because TC are using a slightly modified non-standard GZIP format, which makes it impossible to extract using standard UNIX utilities like gunzip, tar, etc. First we extract the rootfs.tar.gz file from the updater using dd:


    $ dd if=dittox4_RC_1.3.00_build_91.exe of=rootfs.tar.gz bs=1 count=12251075 skip=5343278
    12251075+0 records in
    12251075+0 records out
    12251075 bytes transferred in 88.093957 secs (139068 bytes/sec)


    If we just try to gunzip it, it fails:


    $ gunzip rootfs.tar.gz
    gunzip: rootfs.tar.gz: not in gzip format


    It's not recognized by "file", either:


    $ file rootfs.tar.gz
    rootfs.tar.gz: data


    Why? Let's take a look at the GZIP header, which should start with the magic bytes 0x1f 0x8b:

    [code]
    $ hexdump -C rootfs.tar.gz | head
    00000000 1f 0b 08 0c 00 6f 6f 70 59 00 03 51 6c 3d 6b 77 |.....oopY..Ql=kw|
    00000010 5b 36 32 45 79 2a 7e 0a 54 4e 57 47 49 56 14 48 |[62Ey*~.TNWGIV.H|
    00000020 3d 1d 5d 4c 38 7b 5d 58 69 7d 6a 1e 38 3e 16 33 |=.]L8{]Xi}j.8>.3|
    00000030 3b 3d 6d 61 0f 0f 44 42 12 2f 78 60 2a 41 5a 56 |;=ma..DB./x`*AZV|
    00000040 72 72 5f 6b 6f 4c 00 24 28 59 0e 5b 6c 5c 4a 5d |rr_koL.$(Y.[l\J]|
    00000050 1e 08 21 44 49 00 1c 19 0c 06 18 4b 41 60 41 25 |..!DI......KA`A%|
    00000060 56 7f 32 69 76 60 41 68 76 5b 78 7b 34 3b 6d 2b |V.2iv`Ahv[x{4;m+|
    00000070 7c 4c 43 42 13 3b 69 77 5b 76 27 49 5b 6e 77 1f ||LCB.;iw[v'I[nw.|
    00000080 58 36 3c 78 6e 3f 61 6d 75 33 76 51 64 49 26 53 |X600000090 1e 30 76 6a 24 66 09 77 7d 61 4b 7a 7b 60 56 3d |.0vj$f.w}aKz{`V=|
    [/code]

    Aha! The header has custom magic of 0x1f 0x0b! I changed it to standard GZIP using a hex editor and tried again:


    $ file rootfs.tar.gz
    rootfs.tar.gz: gzip compressed data, extra field, last modified: Wed Oct 10 18:25:04 2029, from FAT filesystem (MS-DOS, OS/2, NT)


    That's better. But it still doesn't extract:


    $ gunzip rootfs.tar.gz
    gunzip: data stream error
    gunzip: rootfs.tar.gz: uncompress failed


    There's obviously more going on under the hood than just broken GZIP header magic. At this point I dove into the format of GZIP headers and started messing with bytes to see if I could get it to work, but the best I could in a short period of time were CRC errors.

    At this point I'm going to give up on doing the decompression on my laptop and instead I'm going to do it on the Ditto X4 itself, which MUST be able to gunzip and untar the rootfs.tar.gz archive. I'll put rootfs.tar.gz on an SD card and see if I can make it decompress. I'll let you guys know how it goes a bit later today.
    Highlighted
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    Gah! It's not going to work because the update process looks for /update.tar and if it's there, boots from the recovery partition to install update.tar. I don't have the recovery partition because my SD card is corrupt, which means I can't untar the update.tar file, which means I'm still hosed.

    Sadly, it looks like my choice of last resort - a trip to Guitar Center - is in order.

    Before I go and do this thing, is there anyone who's willing to take an image of their SD card? It's not hard, not invasive, and not in any way risky! It's a read-only operation. Any takers?
    Highlighted
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    Good news! I found a guy on Craigslist selling an X4 in the town next to me. I've arranged to pay him $20 to go to his place and make a copy of his SD card. Fingers crossed!
    Highlighted
    Contributor - Level 1

    Re: Debugging a bricked Ditto X4

    Gotta Say, I'm very excited to see how this thread pans out.

    I literally was just a few minutes away from purchasing a pigtronix looper with my Christmas bonus to replace my bricked-for-a-year Ditto X4 and I decided to do a quick google search before doing so.

    I had done my own troubleshooting attempting to format the SD card in the hopes it would re-initialize itself with no luck, but your idea to re-image the card from a working Ditto has me crossing my fingers.

    Eagerly awaiting an update!
    Highlighted
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    Success!!!!! Smiley Very Happy Smiley Very Happy Smiley Very Happy Smiley Very Happy My X4 boots and works perfectly now.

    I copied the Craigslist dude's SD card like so:


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


    Then I copied that image onto my original SD card like so:


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


    Then I put it back into my X4 and booted it up. Here's the boot log:

    [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 **
    1024 .
    1024 ..
    12288 lost+found
    1024 opt
    1024 tmp
    1024 etc
    1024 var
    3072 lib
    1024 usr
    1024 mnt
    5120 bin
    3072 sbin
    1024 sys
    1024 boot
    1024 home
    1024 proc
    1024 root
    1024 dev
    ** File not found /boot/splash.working **
    2222108 bytes read in 825 ms (2.6 MiB/s)

    ## Checking Image at 42000000 ...
    Legacy image found
    Image Name: Linux-2.6.35.3-670-g914558e-g408
    Created: 2017-06-19 18:05:27 UTC
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2222044 Bytes = 2.1 MiB
    Load Address: 40008000
    Entry Point: 40008000
    Verifying Checksum ... OK
    ## Booting kernel from Legacy Image at 42000000 ...
    Image Name: Linux-2.6.35.3-670-g914558e-g408
    Created: 2017-06-19 18:05:27 UTC
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2222044 Bytes = 2.1 MiB
    Load Address: 40008000
    Entry Point: 40008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
    OK

    Starting kernel ...

    Uncompressing Linux... done, booting the kernel.
    Linux version 2.6.35.3-670-g914558e-g40827a5-dirty (parallels@ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #17 PREEM7
    CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
    CPU: VIVT data cache, VIVT instruction cache
    Machine: Freescale iMX28EVK board
    Memory policy: ECC disabled, Data cache writeback
    Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
    Kernel command line: console=ttyAM0,115200n8 rootfstype=ext4 root=/dev/mmcblk0p3 rw rootwait ssp1 env_error= env_state=G
    PID hash table entries: 512 (order: -1, 2048 bytes)
    Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
    Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
    Memory: 128MB = 128MB total
    Memory: 125076k/125076k available, 5996k reserved, 0K highmem
    Virtual kernel memory layout:
    vector : 0xffff0000 - 0xffff1000 ( 4 kB)
    fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
    DMA : 0xfde00000 - 0xffe00000 ( 32 MB)
    vmalloc : 0xc8800000 - 0xf0000000 ( 632 MB)
    lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
    modules : 0xbf000000 - 0xc0000000 ( 16 MB)
    .init : 0xc0008000 - 0xc002a000 ( 136 kB)
    .text : 0xc002a000 - 0xc044c000 (4232 kB)
    .data : 0xc044c000 - 0xc047ad00 ( 188 kB)
    SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
    Hierarchical RCU implementation.
    RCU-based detection of stalled CPUs is disabled.
    Verbose stalled-CPUs detection is disabled.
    NR_IRQS:288
    Console: colour dummy device 80x30
    console [ttyAM0] enabled
    Calibrating delay loop... 215.55 BogoMIPS (lpj=107776)
    pid_max: default: 32768 minimum: 301
    Security Framework initialized
    SELinux: Initializing.
    Mount-cache hash table entries: 512
    CPU: Testing write buffer coherency: ok
    regulator: core version 0.5
    NET: Registered protocol family 16
    regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal
    regulator: vdddbo: 800 <--> 1575 mV fast normal
    regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal
    vddio = 3380000, val=10
    regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal
    regulator: overall_current: fast normal
    regulator: vbus5v:
    regulator: mxs-duart-1: fast normal
    regulator: mxs-bl-1: fast normal
    regulator: mxs-i2c-1: fast normal
    regulator: mmc_ssp-1: fast normal
    regulator: mmc_ssp-2: fast normal
    regulator: charger-1: fast normal
    regulator: power-test-1: fast normal
    regulator: cpufreq-1: fast normal
    i.MX IRAM pool: 124 KB@0xc8820000
    Initializing SSP1 pins
    usb DR wakeup device is registered
    IMX usb wakeup probe
    audit: cannot initialize inotify handle
    bio: create slab at 0
    SCSI subsystem initialized
    Freescale USB OTG Driver loaded, $Revision: 1.55 $
    usbcore: registered new interface driver usbfs
    usbcore: registered new interface driver hub
    usbcore: registered new device driver usb
    Advanced Linux Sound Architecture Driver Version 1.0.23.
    Switching to clocksource mxs clock source
    NET: Registered protocol family 2
    IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
    TCP established hash table entries: 4096 (order: 3, 32768 bytes)
    TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
    TCP: Hash tables configured (established 4096 bind 4096)
    TCP reno registered
    UDP hash table entries: 256 (order: 0, 4096 bytes)
    UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
    NET: Registered protocol family 1
    RPC: Registered udp transport module.
    RPC: Registered tcp transport module.
    RPC: Registered tcp NFSv4.1 backchannel transport module.
    Bus freq driver module loaded
    IMX usb wakeup probe
    usb h1 wakeup device is registered
    mxs_dma_apbx_reset 6
    audit: initializing netlink socket (disabled)
    type=2000 audit(0.273:1): initialized
    msgmni has been set to 244
    alg: No test for stdrng (krng)
    cryptodev: driver loaded.
    Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
    io scheduler noop registered
    io scheduler deadline registered
    io scheduler cfq registered (default)
    Console: switching to colour frame buffer device 100x30
    mxs-duart.0: ttyAM0 at MMIO 0x80074000 (irq = 47) is a DebugUART
    mxs-auart.0: ttySP0 at MMIO 0x8006a000 (irq = 112) is a mxs-auart.0
    Found APPUART 3.1.0
    mxs-auart.1: ttySP1 at MMIO 0x8006c000 (irq = 113) is a mxs-auart.1
    Found APPUART 3.1.0
    brd: module loaded
    loop: module loaded
    vl3-spi vl3-spi.0: Max possible speed 120000 = 120000000/2 kHz
    vl3-spi vl3-spi.0: at 0x80014000 mapped to 0xF0014000, irq=84, bus 1, DMA ver_major 4
    ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
    fsl-ehci fsl-ehci: Freescale On-Chip EHCI Host Controller
    fsl-ehci fsl-ehci: new USB bus registered, assigned bus number 1
    fsl-ehci fsl-ehci: irq 93, io base 0x80080000
    fsl-ehci fsl-ehci: USB 2.0 started, EHCI 1.00
    usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
    usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
    usb usb1: Product: Freescale On-Chip EHCI Host Controller
    usb usb1: Manufacturer: Linux 2.6.35.3-670-g914558e-g40827a5-dirty ehci_hcd
    usb usb1: SerialNumber: fsl-ehci
    hub 1-0:1.0: USB hub found
    hub 1-0:1.0: 1 port detected
    fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
    fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 2
    fsl-ehci fsl-ehci.0: irq 92, io base 0x80090000
    fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
    usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
    usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
    usb usb2: Product: Freescale On-Chip EHCI Host Controller
    usb usb2: Manufacturer: Linux 2.6.35.3-670-g914558e-g40827a5-dirty ehci_hcd
    usb usb2: SerialNumber: fsl-ehci.0
    hub 2-0:1.0: USB hub found
    hub 2-0:1.0: 1 port detected
    Initializing USB Mass Storage driver...
    usbcore: registered new interface driver usb-storage
    USB Mass Storage support registered.
    ARC USBOTG Device Controller driver (1 August 2005)
    mice: PS/2 mouse device common for all mice
    MXS RTC driver v1.0 hardware v2.3.0
    mxs-rtc mxs-rtc.0: rtc core: registered mxs-rtc as rtc0
    mxs-mmc: MXS SSP Controller MMC Interface driver
    mxs-mmc mxs-mmc.0: mmc0: MXS SSP MMC DMAIRQ 83 ERRIRQ 97
    dcp dcp.0: DCP crypto enabled.!
    ALSA device list:
    No soundcards found.
    TCP cubic registered
    NET: Registered protocol family 17
    mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:00:06 UTC (6)
    Waiting for root device /dev/mmcblk0p3...
    mmc0: new high speed SDHC card at address 0007
    mmcblk0: mmc0:0007 FLMCE 3.70 GiB
    mmcblk0: p1 p2 p3 p4 < p5 p6 p7 >
    EXT4-fs (mmcblk0p3): recovery complete
    EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null)
    VFS: Mounted root (ext4 filesystem) on device 179:3.
    Freeing init memory: 136K
    starting pid 455, tty '': '/root/x4-early-init.sh'
    Performing udev X4 style
    starting pid 461, tty '': '/etc/rc.d/rcS'
    udevd[460]: main: error disabling OOM: No such file or directory
    Mounting /proc and /sys
    Setting the hostname to X4
    Mounting filesystems
    EXT4-fs (mmcblk0p3): re-mounted. Opts: (null)
    mount: mounting usbfs on /proc/bus/usb failed: No such file or directory
    Starting the dropbear ssh server:
    starting pid 499, tty '': '/root/x4-startup.sh'
    EXT4-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended
    EXT4-fs (mmcblk0p2): recovery complete
    EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: barrier=1,data=ordered
    EXT4-fs (mmcblk0p7): warning: maximal mount count reached, running e2fsck is recommended
    EXT4-fs (mmcblk0p7): recovery complete
    EXT4-fs (mmcblk0p7): mounted filesystem with ordered data mode. Opts: commit=10,barrier=1,data=ordered
    EXT4-fs (mmcblk0p5): warning: maximal mount count reached, running e2fsck is recommended
    EXT4-fs (mmcblk0p5): recovery complete
    EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: commit=10,barrier=1,data=ordered
    EXT4-fs (mmcblk0p5): re-mounted. Opts: commit=10
    EXT4-fs (mmcblk0p7): re-mounted. Opts: commit=10
    X4: loading drivers
    DittoX4 led and switch Interface 1.0.00 build 1
    DittoX4 GPIO Keyswitch Driver 1.0.00 build 1
    Timer resolution is 1 nanoseconds
    Sampling interval (useconds) 500000
    DittoX4 Simple LRADC Interface 1.0.00 build 1
    x4_lradc: init
    No device for codec mxs dsp56720
    No device for DAI mxs_dsp56720
    No device for DAI mxs-saif
    mxs-dsp56720 mxs-dsp56720.0: MXS <-> DSP56720 Mutli-channel Audio Driver
    SAIF Machine Driver Initlialized
    DSP56720 CDC (Psuedo Codec Driver)
    asoc: mxs_dsp56720 <-> mxs-saif mapping ok
    ln: /root/user: File exists
    X4: execute application
    cannot determine device number: Inappropriate ioctl for device
    Unnamed|MM:1764000000 BCP:1764000000
    CLI|Starting Thread 1
    CLI|Starting Thread 3
    CLI|Starting Thread 5
    CLI|Starting Thread 6
    CLI|Starting Thread 2
    CLI|Starting Thread 4
    CoreLoopSharedBufferManagerHeap|New Buf (176400) Count=1

    mxs_dma_apbx_reset 5
    mxs_dma_apbx_reset 4
    mxs_dma_apbx_reset 5
    mxs_dma_apbx_reset 4
    Priming soc_playback_stream
    SAIF0 overrun!!! 17
    Starting audio thread.
    High Priority Audio Polling Thread Starting
    Starting audio (looper) monitor thread


    ---------------------------------------------
    DittoX4 Version: 1.3.00 BUILD 89
    ---------------------------------------------
    x4> CLI|Connecting session.
    CLI|Connected.
    CLI|Finished loading session.

    x4>
    [/code]

    And the pedal works Smiley Happy Smiley Happy Smiley Happy For anyone who cares, you can get a root shell by running the "quit" command at the X4 prompt. The root user has no password:

    [code]
    x4> quit

    Quitting.

    x4> Deleting audiothread
    CLI|Flushing IO...
    CLI|Done.
    CLI|closeSession Complete
    mxs_dma_apbx_freeze 5
    mxs_dma_apbx_unfreeze 5
    mxs_dma_apbx_disable 5
    mxs_dma_apbx_freeze 4
    mxs_dma_apbx_unfreeze 4
    mxs_dma_apbx_disable 4
    SAIF0 underrun!!! 1093
    Closing alsa streams...
    Alsa Devices closed.
    Deleting audio_system
    Deleting AudioEngine
    CLI|Requested to quit ioThread.
    CLI|Requested to quit ioThread.
    CLI|Requested to quit ioThread.
    CLI|Requested to quit ioThread.
    CLI|Requested to quit ioThread.
    CLI|Requested to quit ioThread.
    CLI|~CoreLooperInterface Done
    Ending audio (looper) monitor thread
    CoreLoopSharedBufferManagerHeap|Memory pool was emptied successfully.
    Quit
    starting pid 738, tty '': '/sbin/getty -L ttyAM0 115200 vt100'

    arm-none-linux-gnueabi-gcc (4.4.4_09.06.2010) 4.4.4
    root filesystem built on Mon, 19 Jun 2017 11:14:08 -0700
    Freescale Semiconductor, Inc.

    X4 login: root
    login[738]: root login on 'ttyAM0'


    BusyBox v1.20.2 () built-in shell (ash)
    Enter 'help' for a list of built-in commands.

    root@X4 ~$ id
    uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
    [/code]

    This could open up the pedal to mods and all sorts of hacks and tricks Smiley Happy

    The SD card image is in the cloud now (SD card image). I don't think it falls foul of copyright issues because I'm not posting anything that TC Electronics doesn't already make publicly available on an SD card in every X4 it sells. I'm kinda hoping that TC will be happy to have a fix that they don't have to support, which brings up an important point that should be obvious but just in case: if you do anything I've done in this post, your warranty is null and void.
    Highlighted
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    I've edited the very first post of this thread so that instructions, download links, etc are provided right at the top to make them easier to find.

    I hope this helps some of you get your pedals back in working order. Good luck!
    Highlighted
    Contributor - Level 1

    Re: Debugging a bricked Ditto X4

    ITS ALIVE!


    You the man, phantomraspberryblower.

    With your instructions I was able to get my DittoX4 up and running.


    I did run into a small hitch along the way which I'll detail below in case any one else has this issue:



    I was not able to image an SD card with balenaEtcher. I tried on two different Win10 computers, two different SD card interfaces (USB and built in), and 3+ SD Cards (various makes/models/capacity).

    Every time I would image the SD card it would fail the verification stage, and leave me with a card that would not work in my pedal.


    ---

    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!

    ----

    I'd also like to point out that it looks like my pedal's original SD card was corrupted beyond the point of re-use. I'm currently using the pedal with a Samsung 64 gig sd card that is working well.





    Thanks again for your work in debugging this issue phantom! Do you have a patreon or pay pal or anything? I'd like to buy you a beer or six!
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    fzzbx wrote:
    ITS ALIVE!
    ...
    With your instructions I was able to get my DittoX4 up and running.


    Yes!! Glad to hear it

    fzzbx wrote:

    I did run into a small hitch along the way which I'll detail below in case any one else has this issue:

    I was not able to image an SD card with balenaEtcher. I tried on two different Win10 computers, two different SD card interfaces (USB and built in), and 3+ SD Cards (various makes/models/capacity).

    Every time I would image the SD card it would fail the verification stage, and leave me with a card that would not work in my pedal.


    ---

    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!

    ----

    I'd also like to point out that it looks like my pedal's original SD card was corrupted beyond the point of re-use. I'm currently using the pedal with a Samsung 64 gig sd card that is working well.


    Thanks for the heads up, I'll update the first post.

    fzzbx wrote:

    Thanks again for your work in debugging this issue phantom! Do you have a patreon or pay pal or anything? I'd like to buy you a beer or six!


    It's my pleasure, and I don't need money. If you give a little to a charity I'd be more than happy. Thanks!
    Highlighted
    Contributor - Level 2

    Re: Debugging a bricked Ditto X4

    phantomraspberryblower, I gotta say that's some excellent engineering work you did. Well done!
    Highlighted
    Triber Moderator

    Re: Debugging a bricked Ditto X4

    Hi all,

    everybody that experiences issues with his or her Ditto X4, please get in touch with our tech support teams via the link below.

    We have seen the described issue with some SD cards failing and the units can be fixed as part of service repair.

    an indication for possible SDcard failure leading to the non-booting issue is if the unit cannot be brought into boot mode and a tried firmware update fails. Our supporters will assist you assessing the problem and advise you how to proceed best and have your units fixed.

    You can contact our tech support team via the following link:
    https://www.tcelectronic.com/brand/tcelectronic/support#googtrans(en|en)

    Alternativly, you can also write to: CARECREA@MUSICTRIBE.COM

    Please include your product serialnumber in your support request and try if you can get your Ditto X4 into boot mode as described below:

    Preparing the firmware update/setting your Ditto X4 into Boot mode


    - Unplug all cables (including the power supply) from your TC pedal.
    - Connect the pedal to your computer using a USB cable.
    - Press and hold (min 3 seconds) the leftmost footswitch (Lp1) on your Ditto X4.
    - Insert the DC power supply plug while keeping the switch pressed.

    !!!The leftmost LED on your pedal should turn green. -- wait until the the loop1 LED turns off – now release the Loop1 footswitch and wait until all LEDs are green – you are now in boot mode!!

    -Release the footswitch

    If the LEDS are not turning green (and stay lit) - the SD card might have failed and you should get in touch with our support team to help you getting your unit fixed.

    best regards, Mike
    TC Mike | Triber Moderator, Music Tribe Did you find my post helpful? Give kudos or mark it as a solution! Community Guidelines | FAQs