Minute not loading after de_Fuse

[qubitstech]

Hi,

I'm having trouble with a Wii U console I'm trying to repair. The console has a blinking blue LED when powered on.

I've installed a Pico to run de_Fuse (PTB didn't work), and it seems to be running but gets stuck in a loop and never finishes. Log below.

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 3224:0
Results:
Winner! 0xf368
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
0f
8f
0f
00
80
01
81
00
80
01
81
00
80
01
81
00
80
01
81
0f
8f
0f
00
01
81
00
80
01
81
00
80
01
81
00
80
01
81
00
80
0f
8f
0f
00
80
01
81
00
80
01
81
00
80
01
81
00
80
01
81
0f
8f
0f
00
01
81
00
80
01
81
00
80
01
81
00
80
01
81
00
80
0f
8f
0f
00
80
01
81
00
80
01
81
00
80
01
81
00
80
01
81
0f
8f
0f
00
01
81
00
80
01
81
00
80
01
81
00
80
01
81
00
80
0f
8f
0f
00
80
01
81
00
80
01
81
00
80
01
81
00
80
01
81
0f
8f
0f
00
01
81
00
80
01
81
00
80
01
81
00
80
01
81
00
80
0f
8f
0f
00
80
01
81
00
80
01
81
00
80
01
81
00
80
01
81
0f
8f
0f
00
01
81
00
80
01
81
00
80
01
81
00
80
01
81
00
80
0f
8f
0f
00
80
01
81
00
80
01
81
00
80
01
81
00
80
01
81
0f
8f
0f
00
01
81
00
80
01
81
00
80
01
81
00
80
01
[pico] Changed state: WIIU_STATE_NEEDS_DEFUSE -> WIIU_STATE_DEFUSED
[pico] Changed state: WIIU_STATE_DEFUSED -> WIIU_STATE_MONITORING
0207!FLAG84FLAG84CF%10(MEM2U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f��U�U�U�U�U�U�U�U�f00f

I've truncated the last line as you get the idea - this just repeats forever with a flashing purple LED until I turn the console off. Doesn't matter if there's a fw.img on the SD card or not, I only ever get the purple flashing LED. so I guess it's not even trying to load from the card yet?

It's the first time I've used de_fuse, so I'm not really sure what to make of this. I notice the last normal message is memory related - does this suggest a DRAM issue?

 

[neverendsDull]

I encountered the same "pattern", SDIO said this is caused by faulty RAM=hardware failure
Symptom: PTB not working, flashing blue indicator, and de_fuse stuck at loading minute menu.

 

[SDIO]

So the minute boot1 is executing but if fails at MEM2 (DRAM). At least it looks like that from the messed up output. Somehow it is outputting in ascii and not in hex mode.

 

[qubitstech]

Thanks for the replies. I'm using screen to read the serial output, not sure if that has something to do with output formatting.

I've ran the two memtest boot1 images from this post, and got an expected result.

[pico] Changed state: WIIU_STATE_NEEDS_DEFUSE -> WIIU_STATE_DEFUSED
[pico] Changed state: WIIU_STATE_DEFUSED -> WIIU_STATE_MONITORING
0207!CF%10(MEM2U�U�U�U�U�U�U�U�beef[Pico] Switching to data mode...

fe ba ad aa aa ff ff 00 00 10 00 00 04 10 00 00 
08 ba ad aa aa ff ff 00 00 10 00 00 0c 10 00 00 
10 ba ad aa aa ff ff 00 00 10 00 00 14 10 00 00 
18 ba ad aa aa ff ff 00 00 10 00 00 1c 10 00 00 
20 ba ad aa aa ff ff 00 00 10 00 00 24 10 00 00 
28 ba ad aa aa ff ff 00 00 10 00 00 2c 10 00 00 
30 ba ad aa aa ff ff 00 00 10 00 00 34 10 00 00 
38 ba ad aa aa ff ff 00 00 10 00 00 3c 10 00 00 
40 ba ad aa aa ff ff 00 00 10 00 00 44 10 00 00 
48 ba ad aa aa ff ff 00 00 10 00 00 4c 10 00 00 
50 ba ad aa aa ff ff 00 00 10 00 00 54 10 00 00 
58 ba ad aa aa ff ff 00 00 10 00 00 5c 10 00 00 
60 ba ad aa aa ff ff 00 00 10 00 00 64 10 00 00 
68 ba ad aa aa ff ff 00 00 10 00 00 6c 10 00 00 
70 ba ad aa aa ff ff 00 00 10 00 00 74 10 00 00 
78 ba ad aa aa ff ff 00 00 10 00 00 7c 10 00 00 
80 ba ad aa aa ff ff 00 00 10 00 00 84 10 00 00 
88 ba ad aa aa ff ff 00 00 10 00 00 8c 10 00 00 
90 ba ad aa aa ff ff 00 00 10 00 00 94 10 00 00 
98 ba ad aa aa ff ff 00 00 10 00 00 9c 10 00 00
...

Guess this one is heading for the parts bin.

From a memtest log, is it possible to tell which DRAM module has failed?

 

[SDIO]

Which test did you run exactly?

 

[qubitstech]

The log previously posted was from boot1-memtest-f-noblock.img.

boot1-memtest-0-noblock.img gives the following:

0207!CF%10(MEM2U�U[Pico] Switching to data mode...

fe ba ad aa aa 00 00 ff ff 10 00 00 00 10 00 00
04 ba ad aa aa 00 00 ff ff 10 00 00 08 10 00 00
0c ba ad aa aa 00 00 ff ff 10 00 00 10 10 00 00
14 ba ad aa aa 00 00 ff ff 10 00 00 18 10 00 00
1c ba ad aa aa 00 00 ff ff 10 00 00 20 10 00 00
24 ba ad aa aa 00 00 ff ff 10 00 00 28 10 00 00
2c ba ad aa aa 00 00 ff ff 10 00 00 30 10 00 00
34 ba ad aa aa 00 00 ff ff 10 00 00 38 10 00 00
3c ba ad aa aa 00 00 ff ff 10 00 00 40 10 00 00
44 ba ad aa aa 00 00 ff ff 10 00 00 48 10 00 00
4c ba ad aa aa 00 00 ff ff 10 00 00 50 10 00 00
54 ba ad aa aa 00 00 ff ff 10 00 00 58 10 00 00
5c ba ad aa aa 00 00 ff ff 10 00 00 60 10 00 00
64 ba ad aa aa 00 00 ff ff 10 00 00 68 10 00 00
6c ba ad aa aa 00 00 ff ff 10 00 00 70 10 00 00
74 ba ad aa aa 00 00 ff ff 10 00 00 78 10 00 00
7c ba ad aa aa 00 00 ff ff 10 00 00 80 10 00 00
84 ba ad aa aa 00 00 ff ff 10 00 00 88 10 00 00
8c ba ad aa aa 00 00 ff ff 10 00 00 90 10 00 00
94 ba ad aa aa 00 00 ff ff 10 00 00 98 10 00 00
9c ba ad aa aa 00 00 ff ff 10 00 00 a0 10 00 00
a4 ba ad aa aa 00 00 ff ff 10 00 00 a8 10 00 00
ac ba ad aa aa 00 00 ff ff 10 00 00 b0 10 00 00
b4 ba ad aa aa 00 00 ff ff 10 00 00 b8 10 00 00
bc ba ad aa aa 00 00 ff ff 10 00 00 c0 10 00 00
...

 

[SDIO]

Going trough my notes, I the mapping of the addresses to the chips works like this:

Here the link: https://github.com/jan-hofmeier/min...287d225dd6e495d100e8b/source/main.c#L263-L312

Going by the name of the file you run, I think it wrote all f.

Matching your output to the code:

serial_send_u32(0xBAADAAAA); // -> ba ad aa aa
serial_send_u32(readback);   // -> 00 00 ff ff
serial_send_u32(j);          // -> 10 00 00 00 (this is the address)
serial_send_u32(badend);     // -> 10 00 00 04 (end of the bad range)

Applied to your output we get for the start of the bad ranges:

10 00 00 00 - 10 00 00 04
10 00 00 08 - 10 00 00 0c
10 00 00 10 - 10 00 00 14
10 00 00 18 - 10 00 00 1c
10 00 00 20 - 10 00 00 24
10 00 00 28 - 10 00 00 2c
10 00 00 30 - 10 00 00 34
10 00 00 38 - 10 00 00 3c
10 00 00 40 - 10 00 00 44
10 00 00 48 - 10 00 00 4c
10 00 00 50 - 10 00 00 54
10 00 00 58 - 10 00 00 5c
10 00 00 60 - 10 00 00 64
10 00 00 68 - 10 00 00 6c
10 00 00 70 - 10 00 00 74
10 00 00 78 - 10 00 00 7c
10 00 00 80 - 10 00 00 84
10 00 00 88 - 10 00 00 8c
10 00 00 90 - 10 00 00 94
10 00 00 98 - 10 00 00 9c
10 00 00 a0 - 10 00 00 a4
10 00 00 a8 - 10 00 00 ac
10 00 00 b0 - 10 00 00 b4
10 00 00 b8 - 10 00 00 bc
10 00 00 c0 -

So for this one it's channel 0, but if there was something on channel 1, we wouldn't see it from that limited output, since the interleave is 256.
So we see that it is always one word bad and then one word good again.

Looking at the read back value, which is the same for every bad word: 00 00 ff ff
So the lower half looks expected (fffff) but the upper half (chip1) (0000) is just zeroed out.

Looking at the table Channel 0, Chip 1 gives us U4.

I hope I didn't make any mistake here... It's a long time since I looked at this the last time.

 

[qubitstech]

Thanks, that's really useful info.

I do have longer logs, and if I look a bit further I see

ba ad aa aa ff ff 00 00 10 00 00 ec 10 00 00 f0
ba ad aa aa ff ff 00 00 10 00 00 f4 10 00 00 f8
ba ad aa aa ff ff 00 00 10 00 00 fc 10 00 01 00
ba ad aa aa ff ff 00 00 10 00 02 04 10 00 02 08
ba ad aa aa ff ff 00 00 10 00 02 0c 10 00 02 10
ba ad aa aa ff ff 00 00 10 00 02 14 10 00 02 18

and if I'm reading this correctly, we have skipped addresses in the 0x100 range which would be channel 1. So channel 1 looks fine.

Interestingly, I took another log today before poking around again, and the incorrect readback values are no longer all 00 00 (a few of them were 00 ff or ff 00). So I decided to heat U4 with hot air (only on low and for about 30s), and the values changed again. Not sure how diagnostically useful that is, but I thought it was interesting to see.

Anyway, I managed to remove U4. I was expecting to see all zeros, but I now get inconsistent results. The address pattern seems to have changed too.

ba ad aa aa ff ff ff b7 10 00 00 00 10 00 00 78
ba ad aa aa ff ff 00 ff 10 00 00 7c 10 00 00 f8
ba ad aa aa ff ff 00 ff 10 00 00 fc 10 00 01 00
ba ad aa aa ff ff ff 75 10 00 02 00 10 00 02 68
ba ad aa aa ff ff 00 ff 10 00 02 6c 10 00 02 d8
ba ad aa aa ff ff 00 ff 10 00 02 dc 10 00 03 00
ba ad aa aa ff ff ea d3 10 00 04 00 10 00 04 48
ba ad aa aa ff ff 00 ff 10 00 04 4c 10 00 05 00
ba ad aa aa ff ff e1 3e 10 00 06 00 10 00 06 30
ba ad aa aa ff ff 00 ff 10 00 06 34 10 00 06 a0
ba ad aa aa ff ff 00 ff 10 00 06 a4 10 00 07 00
ba ad aa aa ff ff a1 7f 10 00 08 00 10 00 08 10
ba ad aa aa ff ff 00 ff 10 00 08 14 10 00 08 80
ba ad aa aa ff ff 00 ff 10 00 08 84 10 00 08 f8
ba ad aa aa ff ff 00 ff 10 00 08 fc 10 00 09 00
ba ad aa aa ff ff ff 75 10 00 0a 00 10 00 0a 68
ba ad aa aa ff ff 00 ff 10 00 0a 6c 10 00 0a d8
ba ad aa aa ff ff 00 ff 10 00 0a dc 10 00 0b 00
ba ad aa aa ff ff ea d3 10 00 0c 00 10 00 0c 48

Not sure what to make of this. The failed ranges look larger which isn't what I was expecting to see. Have I damaged the board while removing U4, or could U5 have been the culprit after all?

Also, I realised the board I was planning to use as a donor has Samsung DRAM, while this is Micron. Is the Wii U picky about DRAM brands?