Canon EOS R5 / R6

[yokashin]

Congratulations!
 

[chris_overseas]

Very nice - I can confirm it works on the R5 too! I had been using an SDXC card with my previous attempts, worked fine when I tried it with an SDHC. Same combination to activate it, PLAY then SET.

[yourboylloyd]

This is awesome!

Does anyone have any idea why SDXC wouldn't work?

[names_are_hard]

It's easy to guess a bunch of reasons why, but it doesn't really matter.

Since SDXC tend to be larger cards, I'd like to test the theory that it's not SDXC, but really the size of the card that matters.  Apparently there are 32GB SDXC cards, so if 64GB SDHC can be shown to work, and 32GB SDXC shown to not work, on the same cam, then it's probably SDXC being the problem.  Again, doing this test isn't important - we know small-ish SDHC works, and that's easy to do.

[Walter Schulz]

There is a mixup of terms.
SDHC is limited to card sizes up to 32 GByte. Any larger card is - by definition - SDXC.
I think you meant to talk about partition size and want to experiment with that.

[names_are_hard]

No, I was just making a bad assumption, I thought SDXC was a speed / bus change

Could easily be some size check then, if it's done on the disk, not the partition.  Could still test a 32GB version of SDHC and SDXC.

[Walter Schulz]

Good luck finding a 32 GB SDXC! 
https://www.sdcard.org/consumers/choices/file_system/index.html
I don't say they don't exist ... https://www.dpreview.com/articles/0658120146/pretecsdxc
just hard to find and old GByte vs. GiByte mixup doesn't really help ...

[names_are_hard]

Probably easier to reverse the rom to find out the reason

[Walter Schulz]

Okay, all this dumping was a lot of fun!
Where to go now? There are some people looking for a solution to deal with R5/R6's timers. And srsa opened the way to run a command set by just pressing 2 keys.
Easy to poke some unwanted registers, too.

[c_joerg]

Canon Basic can do a lot more as you can see from these tread.
https://chdk.setepontos.com/index.php?topic=13522.0

This is a M100 snapshot of a Canon Basic Script that I got from srsa.



Perhaps this could also be used to make the temperatures of the R5 visible

[Ant123]

Probably easier to reverse the rom to find out the reason

I assume that on SDXC cards the system uses a separate driver / library for EXFAT, which is loaded after checking the card for a signature.
I have the opposite situation with the EOS M3: I would not want to buy a SDXC card if it does not work with a CHDK.
Perhaps the same situation will be with ML when (and if) it will be implemented for new cameras.

[Walter Schulz]

Perhaps this could also be used to make the temperatures of the R5 visible

What are you waiting for? The string in Canon's code is most likely EFIC_TEMP and there is a script to decompile ROM contents*. I don't have the time right now to do that. I'm not a programmer but this looks like an easy task.

*Dang! It is not yet confirmed to work with Digic X! a1ex?

[Ant123]

Walter Schulz
You should understand that EOS M100 uses PowerShot based firmware and Canon Basic command set could be different for EOS R. Finding a string in a ROM dump doesn't mean that it can be easily accessed with Canon Basic, especially without testing it on a real camera.

[kitor]

I have a feeling that with R5 Canon may have created the spark that this project needed to move forward 
Quick break in that we achieved when topic is hot may help that.

Looks that R5 may really become next 5D2.

[visionrouge.net]

I found crazy that the RTC is a dedicated chip place in the middle of nothing and so easy to access.
I have a simple question.
The RTC holds the time and day and can be access by the I2C bus. Either to program the time and the alarm and countdown.
But when a alarm is set up, Pin 6 is the IRQ line. Usually, the IRQ adk the processor to check what is happening by reading the I2C.

Is simply cutting the pin 6 signal enough for not triggering the IRQ signal and shoot forever? (and keep time of the day and date active?)

You need to have this pin a High level with a pull up resistor linked to pin 8 if it's not already the case (low level is IRQ Active)

[71m363nd3r]

I found crazy that the RTC is a dedicated chip place in the middle of nothing and so easy to access.
I have a simple question.
The RTC holds the time and day and can be access by the I2C bus. Either to program the time and the alarm and countdown.
But when a alarm is set up, Pin 6 is the IRQ line. Usually, the IRQ adk the processor to check what is happening by reading the I2C.

Is simply cutting the pin 6 signal enough for not triggering the IRQ signal and shoot forever? (and keep time of the day and date active?)

You need to have this pin a High level with a pull up resistor linked to pin 8 if it's not already the case (low level is IRQ Active)

Thanks for the info & your time that you invested.

[Ant123]

Is simply cutting the pin 6 signal enough for not triggering the IRQ signal and shoot forever? (and keep time of the day and date active?)

If it was your question my answer is "no".
The processor has enough timers to count the heat and RTC is needed only when camera is powered off.
On EOS R cameras RTC probably can be used to wake up the camera.
Anyway cutting PCB lines is bad idea. It's better to wait for a software solution.

[stillinsane]

If cutting the lines would work I would still mod the Hardware.

[visionrouge.net]

Well, it may be a bit more complicated.
If you put some fact together:
-Removing the battery cell reset the fake overheat timer, reset the time and date and few shooting parameters, but keep others as custom functions. So a memory is also powered with this battery. This is very common and few RTC chip also have internal memory to do 2 functions in one (RTC+limited amount of parameters)
This RX8130 do not have a memory register. So it have to be another chip somewhere to do so.

-The amount of chip powered by the 3.3V cell have to be as limited as possible and more likely close to the cell area. This is to keep backup, the power usage should be as tiny as possible. It uses 300 Nano Ampere in sleep mode as reference.

-If it was only a countdown with an IRQ, removing the battery during during the recording and putting back should not affect the countdown. The counter should keep running as soon as the "power good" is restored. So again, it points out to another memory that hold the counter flag.

I still believe a solution as magic lantern is the best way to go.
Either the counter inside the RTC is used for the fake overheat warning, Either it's just a RTC for the time and date.
A chip with a memory along the power line coming from the cell battery is more likely to have a register that can be access and changed by a side software. This software is extremely simple and write time to time a 0 flag in the fake overheat register.

The fake overheat timer starts during the full power state and write a flag when a normal internal timer is reached. This is more likely than using a specific chip for that. Only because the flag is written at the end of the count that removing the battery during shooting allows to restart. So finding this flag and overwriting it will solve this.
I don't see a use of this RTC for overheating purpose as it have very limited alarm feature. (The overheating have 2 steps for example)
I really see a register powered by the 3.3V, so a unique chip alone, not part of any large IC, that holds the key.
That should be also easier to access as it's a dedicated chip, ore likely from a generic brand more than from Canon, so the way to access it should be in a pdf somehow.

[visionrouge.net]

Sorry that I can't modify my post.

Ok, here are new thouht after thinking a bit.

Something is bothering me is the recovery time.
Even without regular camera battery, or by pushing the time.
The recovery time is not reduced.

If it was just a flag to a memory that start to count, it will not be able to know how long the camera was actually off.
It have to be a counter, not just a date stamp difference.
This overheat counter IS inside this chip for sure. cause it can't hold 2 different date and the internal counter are quite limited.

Either the current overheat time is written inside a eeprom, and so compare on boot, either there is a timer that keep running even without battery.
After 2 hour of "fake cool down"; the camera is powering again and check the value of this counter. If it reached the end, you can go again. If not, you have to wait.
The second possibility is that the camera compare the time on boot and do a simple subtraction to know if the elapsed time is enough. The various test kind of shows that it is not working.

To make sure about the second possibility and twist it a bit
I would love someone to do a simple test.
Put the camera on overheat and lock (after 20mn recording video) and keep the battery door open with the scerw hack or use dumb battery the entire time
Change the date  or time to move it to the next day.
Now, try 2 different things:

Remove the camera battery with the drop system. Is restarting check the new day? (But not the flag?)

Or simple turn off the camera, remove the battery and start again. is the second restart is able to do the math between both time? (So the overheat time is stored on eeprom/a counter is runnin during no battery time)

Does it makes sense to test this?

[yourboylloyd]

I would love someone to do a simple test.
Put the camera on overheat and lock (after 20mn recording video) and keep the battery door open with the scerw hack or use dumb battery the entire time
Change the date  or time to move it to the next day.
Now, try 2 different things:

Remove the camera battery with the drop system. Is restarting check the new day? (But not the flag?)

Or simple turn off the camera, remove the battery and start again. is the second restart is able to do the math between both time? (So the overheat time is stored on eeprom/a counter is runnin during no battery time)

Does it makes sense to test this?

I'll do it now on my R6 and a dummy battery.

[yourboylloyd]

GOOD NEWS!!

Results:

• I let the camera overheat after 29:59 + 8:07 mins of recording. Was not able to record anything
• I changed the date and time to one day later and confirmed then went back to canon menu
• Dummy battery disconnect immediately after changing date and time
• Overheating times seems to have reset. The date and time that was changed saved on reboot. All footage was recorded to the SD card successfully
• I proceeded to record in a cooler room. It recorded for 29:59 + 13:03 then overheated. So being in a cooler room did help
• I then disconnected the dummy battery WITHOUT changing the date and time +1 day. I turned the camera back on and the overheating warning was still there.
• I also tried changing the date +1 day and then waiting a few seconds in liveview, then battery pull. The overheating warning was still there.
• I changed the date +1 again and immediately removed the battery. Voila. Overheating timer gone! All other settings saved.

TLDR; basically, unlimited record time. All footage saved. If camera is overheating, change date +1 day and immediately pull dummy battery to reset overheating timer.

Thanks visionrouge(dot)net for the idea! This makes using this camera extremely worry free professionally for me. I wonder if we can make a script that can emulate those steps to trick the overheating timer. I encourage someone else to replicate this test on R6 and R5

*It must be noted that I have bootflag enabled on my EOS R6. Not sure if it means anything in relation to this test.

** It also must be noted that the files were split into 4GB files. I'm not sure if that's the default setting because I've never recorded that long. I realized that I formatted my 128GB card as FAT32 instead of exFAT so this makes sense.

[visionrouge.net]

I'm so happy!
Thanks for trying.

YES!!!!
Please quote my company for such!

[visionrouge.net]

So, the camera DO a  simple time difference between the actual last overheat and the actual time, but as you drop the battery, the time change bit is not read.
The boot just read the time present in the RTC at this time.

I guess the software engineer have applied a filter to not do a time difference if the day/time is changed, but this is bypassed by this kind of boot.

It also shows the RTC do not run a overheat timer when camera is off.

The compilation of finding are online  https://www.visionrouge.net/canon-r5-overheating-hack-solved/ (please click on the advertising at the botom to offer me 5 cent, I may be able to buy a new SD card !)
(And getting updated right now with pictures and all)
I'm so excited to find such loophole.
We need more R5 test with regular card, but I don't think there are relationship between this and the drop power boot.

I love you all

[a1ex]

Cool hack - it's the clearest proof the "overheating" is timer-based, if you ask me.

As I said: IMO this would be *the* opportunity to make transition to pay-for-ML-feature-development work.

Well, this particular hack is easy enough to automate - I wouldn't be surprised if somebody comes up with a one-click version within the next few days or weeks (also mentioned on Twitter). Motivation is high in the R5/R6 user community - much higher than for porting ML on 5D4, EOS R and the like, in my opinion. So, while it's definitely a low-hanging fruit with high rewards, I don't see anyone paying for a slightly more polished version of this hack. A free one will very likely appear sooner or later, without our involvement.

BTW - I feel a lot safer knowing this hack was discovered by third parties - even if it was documented on our forum. There's no single person behind it - all of the previous iterations paved the way to this version of the hack ("standing on the shoulders of giants"), and I'm pretty sure it will be further refined by the community.

On the other hand, this "overheating" thingie caused quite a stir on the internet, which ended up drawing some of the attention towards our project. That's probably "exploitable" in the sense of "pay-for-development", but primarily for the other models - if I'm not mistaken, the R5 already records 8K raw video (but I haven't touched this camera, so I might be wrong), so the motivation for our enhancements on this model is probably low, besides the overheating timer hack.

Now, back to my (covid-related) research