Possible broken dev MOD Duo

Hello, I think my dev MOD Duo is breaking down. It randomly locks after I hear a relay clicking, probably to put the device in bypass mode. Everything locks up, even serial access (yes, I’ve soldered a serial connection to the board). Is there any way I can revive this unit? What if I could get a hold of a spare Itead Core AW2041 board, could I swap it with the current board as a drop-in replacement? Or is there any other board I could swap it with? Or could it be debugged, i.e. by monitoring ubifs parameters or other things? I think it’s the NAND breaking down but it could also very well be something else. This behavior started after having upgraded to 1.13. I also like to emphasize this is a dev unit, it’s a unit with a failed powder coating and I reckon the insides were b-stock too by the time this unit was put together. So this is in no way an officially released unit, have one of those too and that one shows no sign of wear whatsoever. And I don’t want to toss it in the bin, I use this unit to test things and I also lend this unit to fellow musicians so they can play around with a MOD.

TIA,

Jeremy

is this something you can reliably confirm, or a bias for the unit not having much use before the update?

since you mentioned you were able to reflash the unit a few times, seems at least usb and cpu still work fine. I think it is indeed the nand breaking down.
we have a few Duo coreboard replacements around, but best to ask @jon for this.

PS: you can mount the system RW and edit /boot/*.txt files to take out “quiet” and “loglevel=0” and replace it with “loglevel=9”, so you see any boot failures on the debug serial when something goes wrong.

2 Likes

Didn’t use it that much no, that’s true, so yes, it could have nothing to do with the 1.13 release so yeah, better rule that out. But I can reliably confirm, it’s now that bad that whenever it gets through booting the unit already freezes when I add an affect to the Default pedalboard.

Ok, thanks, will do as soon as I’m 100% sure it’s something with the board.

Awesome, thanks, will definitely give that a go and report back!

Whenever it locks I see no output on the serial console. Same for when it doesn’t boot, then it just hangs at Starting kernel ... :

U-Boot SPL 2020.01-rc4-00036-g8429f79185-dirty (May 07 2020 - 20:11:18 +0100)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from NAND


U-Boot 2020.01-rc4-g8429f79185-dirty (Oct 27 2020 - 12:09:29 +0000) MOD Devices

CPU:   Allwinner A20 (SUN7I)
Model: MOD Duo
I2C:   ready
DRAM:  1 GiB
NAND:  4096 MiB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0 

Loading from nand0, offset 0x2800000
   Image Name:   Linux-6.1.15-rt7-modduo
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4760976 Bytes = 4.5 MiB
   Load Address: 40008000
   Entry Point:  40008000

NAND read: device 0 offset 0x2e00000, size 0x8000
 32768 bytes read: OK
## Booting kernel from Legacy Image at 40008000 ...
   Image Name:   Linux-6.1.15-rt7-modduo
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4760976 Bytes = 4.5 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Kernel Image
   Using Device Tree in place at 43000000, end 43006a94

Starting kernel ...
1 Like

Got a pedalboard with DIE Fluid Synth with a Rhodes soundfont that works perfectly on my working Duo but on the one that is failing I only hear small popping sounds when I hit some keys. As if the samples don’t get loaded in RAM properly. Other, albeit smaller, soundfonts work though.

I propose to get the dev unit booting once (you said it eventually boots sometimes, so do try a few times until it does) and then scp a ~100Mb file into it over and over again, with 60s sleep in between. I think you can easily do a one-liner for this. Leave it overnight or something…

When done, reinstall the 1.13.1 reset data (** without a FEL boot factory reset **)

My theory is that this can trigger the nand checker background process to go through the entire nand and identify and mark bad chunks. The reinstall then makes sure we have valid data using only valid nand chunks.

3 Likes

Thanks! But that doesn’t work unfortunately, after one or two loops I hear a relay clicking right after the file transfer and then the network connection gets cut off :frowning:

it is really dead then… we should replace the SoM

According to U-Boot there are some bad blocks:

Device 0 bad blocks:
  05a00000
  05b00000
  ffc00000
  ffd00000
  ffe00000
  fff00000

Would it work to recreate anything with nand write? That should skip bad blocks. But then which incantation of nand write to use?

You can always try to reinstall the factory user data image a few times… but since the unit literally turned itself off (you could hear the physical relays) I expect the CPU to have issues too.

Ok, thanks, I’ll give that a go.

Restored the factory image reset image 5 times but no improvement unfortunately. If you have a SoM lying around that I could take over I’d be grateful. Otherwise I’ll start scavenging the interwebz for a replacement SoM.

we do yes, send a message to @jon or write to support@mod.audio
@jon is the one answering both :sweat_smile:

2 Likes

@autostatic, I already checked your email.
I will try to get back to you on Friday already with a full solution in place.

Hi João, thanks!!