Try to start it without memory card and connected to PC before start.
Etiquette, expectations, entitlement...
@autoexec_bin | #magiclantern | Discord | Reddit | Server issues
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Show posts MenuQuote from: coon on December 13, 2020, 04:28:00 PM
So only our RXMPU pins differ. Mine meight be wrong.
how do you know that RXMPU is on pin 7? Do you get any response from MPU when sending something there?
Quote from: coon on December 10, 2020, 08:08:14 PM
Thanks for the findings. The connector meight be the same as on RP but as an angled version, so dev kit plus flex pcb meight also work on R6.
Are you sure with the pinout?
It should be:
1:
2: RXICU (1v8)
3: TXICU (1v8)
4: GND
5: Maybe RXMPU (3v3)
6: TXMPU (3v3)
7:
8:
But yours is:
1:
2: RXICU (?)
3: TXICU (?)
4: GND
5:
6: TXMPU (?)
7: RXMPU (?)
8:
Did you also note the voltage levels on each pin?
Quote from: a1ex on March 01, 2019, 01:56:14 PM
It's been in this state for a couple of months; no idea what the issue is.
1. First cold boot (after battery out): usually everything fine. Sometimes starting directly into state 2 or 3, with low probability.
2. Second (warm) boot: almost everything working, except rear dial.
3. Third (warm) boot: DryOS fully booting, GUI on the screen, but camera locked up. No reaction to buttons or card/battery door. Of course, the defect was also present without card, after clearing all Canon settings etc.
Before writing the above message, I've disassembled it a few times, reassembled, but there were no signs of getting better. I could, however, isolate the defect to the rear dial PCB (the one with a black ring on it). If I started the camera without that PCB, it worked fine (no lockups). If I started the camera without the back cover, but just with that PCB attached, the defect was present. There were no signs of damage of that PCB. On that PCB there is a small IC, 7147 ACPZ, talking to the rest of the camera (guess: to the MPU) via SPI. Image annotated by Danieel.
At some point I've started to probe the UART to look for interesting messages. Usually, I turn the camera off from the card cover, as it's faster than from the power switch. With the debug wire attached, I found it easier to use the main switch. After a few reboots I've noticed it no longer locks up. It was working again - that's when I wrote the previous message to document the UART pins.
Reassembled everything, but after putting back the last screws... the problem occured again. Oops! I still had the debug connector accessible, so I've tried to power-cycle it and see if there's anything interesting on the UART pins. While the camera was locked up, I've noticed the MPU restarting itself (printing MON>>> and E1OFF in a loop). Normally, the first message is printed at startup and the last one at shutdown.
Pressed the power switch / mode dial assembly a bit harder, I think, and it's back to life. Will see for how long.
Also found some factory routine that appears to check or calibrate the rear scrollwheel. They didn't seem to help or hurt, except at some point I've got scrollwheel events without any user input (as if the sensitivity was too high). They were gone at next reboot.
Not yet sure whether it was the scrollwheel PCB, or the power switch, or something else. I'm not yet able to get diagnostic logs from the MPU.
Edit: after typing this, the defect is back. One update: from the "completely locked up" state, I can turn off the camera by applying some force on the power switch. Just actuating it normally keeps the camera powered on and locked up, i.e. no reaction at all.
Edit: alive again. Go figure...
Quote from: kitor on February 15, 2019, 07:31:14 AM
I'll add here
- LV is taking so many resources, that it's loosing input on UART. Going into menu makes it reliable + camera output is a few times faster.
For adventurous (as it need's 1v8 UART or 3v3 with voltage divider on TX), simple bootloader dumper:import serial
import sys
start = int('0xE0000000',16)
end = int('0xE0040000',16)
step = int('0x1000',16)
current = start
with serial.Serial('/dev/ttyS6', 115200, timeout=1) as ser, open("dump2.log", 'w', encoding='utf-8') as logfile:
while True:
line = ser.readline()
if line is not b'': #skip timeouts
decoded = line.replace(b'\r\n',b'').decode("UTF-8") #bytes to string
print(decoded)
logfile.write(decoded + '\n')
if b"Mode ON" in line: #enter interactive shell
ser.write(b'akashimorino\r\n')
elif b"K424[1]>" in line: #prompt, start data dump
if current > end:
sys.exit(0)
ser.write(str.encode("d " + hex(current) + " " + hex(step) + "\r\n"))
current += step
Of course you need to reassemble this data into binary form yourself.
UART location/pinout is here.
Yup. Fortunately with bootflag enabled, now RX is sufficient.
Quote from: Sapporo on January 02, 2019, 07:18:00 PM
Opened the software in VirtualBox. I own two Canon 6D. One with Japense/Chinese/English languages and one with international languages. I unlocked the language lock. Now I have two 6D with international languages
Possible to change WiFi/GPS, possible to turn on/off C-log on 5D IV. Dumped 1024 Kb MPU as a bin file. No idea what to do with it.
Quote from: Greg on January 02, 2019, 09:55:19 PM
You did not need this software to change the language restriction.
PROP 0x01000012 -> http://magiclantern.wikia.com/wiki/Properties/550D
Just compare in qemu with the second 6D.
Page created in 0.088 seconds with 13 queries.