Yeah, I wasn’t thinking… 43+ watts is actually a lot of juice compared to the typical 5V 2A / 10watt power supply. Whooooops.
what I fed into the Fin via the phoenix input was 12.8V 3.45A direct from the battery
Yeah, something is not right here! There’s no way the Fin would take that much power without sprouting some flames. If you had the PV and charge controller connected, then maybe the 3.45A was actually flowing into the battery from the PV? Anyway, probably not the main issue here but worth double-checking.
Apparently, the right way to do what I was trying to do was to feed PV AND battery into the PV charge controller, then from the charge controller go to the Fin.
Yeah, charge controllers prefer to have the PV and battery all to themselves to manage, so you typically power your load (ie. the Fin) off the charge controller. But still, again, probably not the main issue and just worth double-checking.
I was having some trouble with that setup and went straight from battery → Fin which is when things went poof.
Still can’t see a problem with what you’ve done. Not ideal for the battery and PV, but the Fin shouldn’t care so much.
I did come across another possibility in the meantime - if you disconnect the battery/PV/controller from the Fin and just plug it into a computer via the Micro-USB port and open Etcher, what do you see? Can you flash it? There’s an outside chance the eMMC has been cooked.
I am completely with you, normally this setup (while not ideal) should be not an issue at all.
The balenaFin in question currently left Jamica and is on the way to me for diagnostics.
I guess it will still take some days, but I will report what I can find 
@barryjump The board has finally arrived - and after wrestling it out of the hands of customs with the usual fine and fees - I finally got it in my hands! 
I got my own/known good balenaFin 1.1.1, plugged out the CM3L+ module and started measuring power draw by using an DPS5005, outputting 12V, with a max current of 1A, “trigger happy” with my thumb on the cut-off switch (not yet needed, but… preparing ;)). Then I measured the power with the CM3.
Then we needed to get to work on the real thing: I popped out the CM3 from @barryjump s poor fin, plugged it in - and saw similar “at rest” current draw. Thats a good thing. Then I popped in the CM3 - the values were all over the bench, but nothing too shocking or exceding the maximum values I saw earlier. But also, as he reported - the LEDs stayed in the “broken” state. Well.
Now was my decision point - what did I trust more? Putting in the “cursed” CM3 module into my fin - or my CM3 into the “cursed” fin? I opted for the second option, putting in my CM3 into the broken fin - powering it on - the power stayed ok, but the LEDs stayed the same. I had a bad feeling. I put in my CM3 into my fin - and was relieved to see it still worked. Ok. It looks like the fin is really toast… so… is there any hope for the CM3? Only one way to find out - putting it into my fin - and nice! It booted!
Ok, the CM3 is ok - the fin is not? Well… I got another idea: I put the “fryed” fin and the “uncursed” CM3 on my PC, started balenaEtcher…
Well, the Sandisk eMMC is fryed! Thats the reason, its the same as with Failing FIN boards and Damaged Fin after power supply failure
So to wrap it up - the CM3 is fine, the balenaFin itself probably too, but the eMMC module on the balenaFin is fryed. I tried multiple rpiboot hacks, mounting it to the pc, trying to low level format it, erasing partitions, rewriting, overwriting with rufus etc - nothing worked sadly. Maybe @hraftery or @ntzovanis have an idea? (I can try to play along with recovery tests. Maybe there is some kind of code that could be run via rpiboot to really low level format the eMMC and getting it working again, other than only trying this via the filesystem mount?)
1 Like
Excellent investigating @nmaas87!
I hope the customs fees/fines did not amount to much. I’m sorry if I incurred you an expense.
Interesting find isolating the problem to the eMMC.
Honestly I didn’t even pay attention to which eMMC module was being used (the Fin’s or the Pi’s). Nor do I recall if my CM3 was the lite version or the one with onboard memory.
I thought my CM3 DID have onboard storage (8gb)… If so, would that mean it’s possible to bypass the ruined Fin eMMC and just use the onboard storage instead?
I wouldnt have a clue how to do that, but in theory it seems possible.
1 Like
Thank you very much - also for providing the Fin!
It was a nice challenge.
And please don’t worry, you also did pay the postage, so everythings fine :)!
( just for the curious, Germany is normally taking about 6-8 Euros fee for the DHL/customs handling and 19% of the products worth. In the past, this only started after 29 Euros or so, but that has been lifted - for quite some time it did not make sense anymore to buy anything at aliexpress etc because each 1 Euro item would then be costing about 10 Euros, thanks to the import fee + the 19%. Luckily, aliexpress is now working around that with some stuff… 
)
All balenaFins do use CM3 Lite Versions, actually, the must use Lite ones.
Reason is that the Fins have onboard eMMC (Sandisk, I think 8, 16 and 32 GB ones) which are hard-soldered. The CM3s “SO-DIMM” interface exposes the SDIO interface needed to communicate with the eMMC, which is then directly connected to the eMMC on the Fin. If the CM3 was not a lite module, you would basically connect two eMMC modules to one port (could also be that the “fat” CM3 do not expose the SDIO interface at all, i don’t know) - but thats the reason why you only can use Lite modules with the Fin. So the 8 GB you saw where there - but on the Fin, not on the CM3. Comes also with the handy idea that if the CM3 where to get damaged, you could just swap it out and continue with your journey - because all data was on the fin
So in absolut theory - it could/may be possible to cut the specific SDIO traces for the eMMC module on the fin and use a fat CM3 module to get the Fin working again. But again, thats just a theory. Other than the fact that no CM3 or anything is available anywhere apart from the really big companies ;). So, I guess I won’t be trying that ^^‘’‘’.
But maybe we can get @hraftery and @ntzovanis in the game with some updates
Thanks again, that was a cool opportunity. Its a bit sad that I cannot fully test the Fin, but I guess chances are good that it (with the exception of the eMMC) would still be working - even after the overcurrent. Nice design !
Oh and another answer:
Basically one could also enable the one time programmable (OTP) bit for booting from USB on the CM3 Lite.
With this, it should try to boot on power on from USB.
This could make the balenaFin available again, but one would need to make all changes necessary in the Raspberry Pi OS installed on the USB stick for taking advantage of all Fin functions.
And this option is NOT reversible, however I read that IF an sdcard / eMMC would be available, it would still boot from this before USB. But thats only what I read.
1 Like
Another idea would be to exchange the eMMC itself:
However, even though it just uses like 10+ signals, it got an like 100+ Ball Grid Array connections. So a little bit of a nightmare to swap out at home. But well, if nothing else helps, maybe its worth a try at some point - just leaving the idea here.
Hey both The 32MB issue is a known problem for the balenaFin and we are willing to exchange the device under RMA. I’ve looped in the relevant people in charge of starting this process and they will be in touch shortly! Thanks for investigating this @nmaas87
1 Like
Awesome! Thanks for the update I think its a testament to how balena handles issues - they work with the customers and try to help - reliable companies and good support are the best, good job
Dear Nico,
This is Stefanos from balena. Please find attached the RMA form we need you to fill out to process your request. Once we have the document signed, we will proceed to schedule a DHL device pickup and start investigating the problem.
Please don’t hesitate to contact us for any further needs.
Best regards,
Stefanos Sakellariou
Balena Ltd - RMA Form- Nico Maas.pdf (414.8 KB)
@stefsak that’s very generous of you guys. @nmaas87 let me know how it works out!
Please let me know if there is any cost involved in the return. Don’t want to impose more fees on you.
1 Like
Thank you
balena did provide a free return ticket and the board has already arrived on saturday at balena.
I am currently waiting for the new board to get send out - but balena managed in the past to work out the customs issues very well, so I think there should be no bad surprises
But thank you very much
1 Like
Roger, wilco
1 Like
@mpous Just going through my thread list and I have not forgotten the topic, but I am still waiting for getting a new Fin or the repaired one back, have not received any update since I mailed it in.
1 Like
Heya, yesterday I got a lovely package from athens - with some awesome content:
The fin somewhat has “accidentally” even doubled its capacity from 8 to 16 GB and is working perfectly <3
Thank you very much @stefsak and @mpous <3! one happy CM3 back from the dead-ish
Thank you so very much
Hi there,
I started back with the new version 1.1.1 16 gb balenaFin and wanted to give some feedback, would probably need some Fin and Etcher guys for this:
a) (Remark): Initially I plugged the balenaFin directly to my old laptop, but I was not able to mount the eMMC, neither with rpiboot nor etcher. In the end it turned out the 16 gb version 1.1.1 seems to be consuming more power than my older 8 gb version. With a powered USB hub this issue was solved after “hacking” etcher (see below)
b) As I was not able to mount the eMMC I went to plug the Fin into Monitor/Keyboard/etc and powered it up externally - and saw balenaOS booting, which was a relief :). Question: Are the Fins pre-flashed with balenaOS from factory? Because I looked the new guy up on balena cli and saw this:
Scanning for local balenaOS devices… Reporting scan results
host: 9c4223a.local
address: x.x.x.202
osVariant: production
However, I could not access it, not even with balena ssh 9c4223a.local, which was curios.
As Marc pointed out, I cannot access it as its a production variant flashed.
But… whats the usecase? I mean preflashing the balenaOS on the Fin as production variant will not enable a user in the field to directly use it… or does it?
c) But now to the more serious thing, I plugged the Fin into the laptop, tried to flash it with baleaEtcher - went to target, saw Compute Module init - then the Act LED of the fin shutdown - and balenaEtcher removed the Compute Module from the list. I tried this again on a second PC (I tested with Win 10 and Win 11) - but it did not work.
Then I tried with my own balenaFin 1.1.1 with 8 GB (which was known good) - but that also did not work.
In fact, it was always the same: 3v3 and 5v lines are red, ACT led is green lit - cm module is initialized by etcher, ACT led goes off and the CM module is removed from the list.
I tried it again with the latest rpiboot ( usbboot/rpiboot_setup.exe at master · raspberrypi/usbboot · GitHub )
- and both Fins just worked. Then I thought, something not right with the bootstrap files in etcher? So I grabbed the relevant files from rpiboot and transplanted them into etcher. And voila - now etcher works agin with the fin.
I also switched the CM4 files, however, there were no issues with CM4. Also the stock balenaEtcher did work with CM4 without issues. balenaFin however does not work anymore with latest 1.7.9 etcher for me…
rpiboot versions I tried and are known working (also when “transplanted” into etcher 1.7.9)
RPIBOOT: build-date Jul 18 2022 version 20220718~085937 5a25e04b (latest)
RPIBOOT: build-date May 5 2022 version 20220504~214218 124154d8
“Transplantation”:
1.) Shutdown etcher
2.) preCM4 files
from usboot:
( usbboot/rpiboot_setup.exe at master · raspberrypi/usbboot · GitHub )
C:\Program Files (x86)\Raspberry Pi\msd
grab:
→ bootcode.bin
→ start.elf
copy to:
C:\Users-\AppData\Local\Programs\balena-etcher\resources\app\generated\modules\node-raspberrypi-usbboot\blobs\raspberrypi
→ bootcode.bin
→ (start.elf needs to be renamed to) start_cd.elf
3.) CM4 files:
from:
C:\Program Files (x86)\Raspberry Pi\msd
grab:
→ bootcode4.bin
→ start4.elf
copy to:
C:\Users-\AppData\Local\Programs\balena-etcher\resources\app\generated\modules\node-raspberrypi-usbboot\blobs\cm4
→ (bootcode4.bin needs to be renamed to) bootcode.bin
→ start4.elf
4.) start etcher, everything works again
In the end, I got the new fin also working on my laptop using the hack above and an external usb hub with power.
Turns out the 16 GB version seems to need just a little bit more power - and it looks like my laptop cannot handle that.
All in all - the Fin seems to be fine, I am very happy - but maybe there is an issue with etcher, as shown above.
Maybe some of the guys and gals could take a look at that? (dunno, maybe I am the only one finding again some strange stuff… ;)) Also the “prod image” on a new board and the power needed would be two interesting talking points.
Thanks,
Nico