search

PiSupply / PiJuice

Resources for PiJuice HAT for Raspberry Pi - use your Pi Anywhere
https://uk.pi-supply.com/collections/pijuice/products/pijuice-portable-power-raspberry-pi
GNU General Public License v3.0
435 stars 103 forks source link

eeprom_erase_error while upgrading to 1.5 #690

Open Jamos1988 opened 3 years ago

Jamos1988 commented 3 years ago

Tried upgrading from GUI, then got this error: eeprom_erase_error Was from 1.4 to 1.5, but it failed and now there is communication error. After rebooting the battery icon in the taskbar is gone. And now when scanning for the i2c, it is gone. Can't do anything with it anymore.

tvoverbeek commented 3 years ago

Try to flash the firmware with the pijuiceboot program. In a terminal window: pijuiceboot 14 <path.to>/PiJuice-V1.5_2021_02_06.elf.binary If that fails use the procedure in https://github.com/PiSupply/PiJuice/tree/master/Firmware#faq. You probably do not need steps 6 and 7 since you already have the firmware file.

Jamos1988 commented 3 years ago

Ok, will do. System is remote so I'll have to shut it down manually when I am there. Hope I don't have to worry leaving it as it is now with a battery connected. In the event that battery charge might be weirdly affected? Hope it's safe until morning then at least. 😟

Jamos1988 commented 3 years ago

Stuck Sending get command.

Followed the steps, removed battery all shutdown, pressed and hold sw3 while power on. No leds flashing so this is ok it seems. While flashing it seems stuck:

image

Now it says error receiving data -1

Jamos1988 commented 3 years ago

There is 3.4 volt on sda and sdl and i2c detect works fine, however no 14 address.

image

Jamos1988 commented 3 years ago

Also tried suggestions from https://github.com/PiSupply/PiJuice/issues/647 No Luck. It now just instantly goes to error receiving data -1

Jamos1988 commented 3 years ago

Ok, it seems I had to completely remove the battery. Red wire alone was not enough, sensor and gnd should also be disconnected.

It is now at:

image

Jamos1988 commented 3 years ago

And again a nope:

image

Now erase error -5

Jamos1988 commented 3 years ago

Ok so maybe I need power on J3 / USB for this, I was only running at GPIO power while starting with sw3. Will try again.

Jamos1988 commented 3 years ago

Because of power to J3 or USB, it will at least succeed in erasing it seems now:

image

Jamos1988 commented 3 years ago

Sad to say, again nope:

image

Jamos1988 commented 3 years ago

Ok, I don't know what to do anymore. Also worth mentioning is after the first try the Pijuice was still responsive with SW1 20 sec shutdown. Also while no LEDs flashing. Now, it doesn't respond to SW1 anymore, so cannot power it down with SW1. It seems completely bricked.

Jamos1988 commented 3 years ago

To sum it up:

Please help!

tvoverbeek commented 3 years ago

How do you power the CM3+? Only via the GPIO? Or via the IO board (if you are using the IO board)? On your i2cdetect output i see responses for 0x40, 0x41, 0x4A, 04x4B, 0x68 and 0x77. 0x4a and 0x4b seem to have OS drivers ('UU'). Can you remove everything else from the I2C bus (except the PiJuice) and see what you get for output from i2cdetect? I do not remember exactly, but an unflashed PiJuice has an I2C address of 0x4?. 0x68 is typically an RTC. Do you have an other RTC or is that part ofr the firmware still working (PiJuice RTC on 0x68)?

Jamos1988 commented 3 years ago

Hi @tvoverbeek I am powering through the GPIO. However, I am powering the Pijuice through both GPIO and J4 / USB. The 0x40 is an INA219, 0x41 is usually also an INA219 but I haven't connected another one so it is weird this pops up. It only appeared after some flashing failures of the Pijuice, and now it is gone again:

image

Indeed the UU are OS drivers based on a dtoverlay, for serial to i2c. I'll try on a separate Pi again. Maybe the unflashed Pijuice has a conflict with some of my existing i2c addresses. I know that my IMU was definitely conflicting, but I had that solved by changing the Pijuice to something else within the GUI. I can imagine that during flashing it would be reset to default and would then conflict again, causing issues?

Jamos1988 commented 3 years ago

Just one question, when a firmware is corrupt or didn't succeed. Should the i2c address be detected? Or, is it just so that an unflashed Pijuice doesn't "broadcast" it's address? I couldn't grasp why the bootloader would give an erase success on address 14, while the default address 14 was not detected in the first place. Does this mean if I try the still undetected address of 0x4 (as you suggest) it would maybe work?

tvoverbeek commented 3 years ago

OK, with a (partially) erased firmware the STM32 bootloader uses I2C address 0x41.

Since the OS saw a device at 0x41 it loaded the INA219 driver for 0x41. Try the following:

Hopefully that succeeds. The original erase failure may be due to a power supply problem (just a guess).

Jamos1988 commented 3 years ago

Thanks! I don't load it with config.txt it is loaded by node-red in this case, unsure about the driver or how to blacklist. Do you know how to blacklist it? Also the 0x41 is not appearing anymore it seems the sw buttons are unresponsive.

On Sun, 21 Mar 2021, 14:50 Ton van Overbeek, @.***> wrote:

OK, with a (partially) erased firmware the STM32 bootloader uses I2C address 0x41.

Since the OS saw a device at 0x41 it loaded the INA219 driver for 0x41. Try the following:

  • Remove the INA219 driver loading (from /boot/config.txt and/or blacklist the module.
  • Make sure the INA219 for 0x41 is not connected.
  • Check with i2cdetect you find something at 0x41, but no 'UU'.
  • Then pijuiceboot 41 /path/to/PiJuice-V1.5_2021_02_06.elf.binary

Hopefully that succeeds. The original erase failure may be due to a power supply problem (just a guess).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/690#issuecomment-803583748, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOISR2E3Y5TOJMB7ZQOTIB3TEX2RTANCNFSM4ZPKACCA .

tvoverbeek commented 3 years ago

@Jamos1988 I am out of ideas. Suggest you contact sales@pi-supply.com and explain your problem with reference to this issue. Also include milan@pi-supply.com. He is the firmware author and board designer and might have suggestions how to proceed. Do not forget to say this is on CM3+. I hope you get this solved.

Jamos1988 commented 3 years ago

Ton thank you so much for all your effort! Greatly appreciated, I'll contact them. I'll let know the end result here.

On Sun, 21 Mar 2021, 20:00 Ton van Overbeek, @.***> wrote:

@Jamos1988 https://github.com/Jamos1988 I am out of ideas. Suggest you contact @. and explain your problem with reference to this issue. Also include @. He is the firmware author and board designer and might have suggestions how to proceed. Do not forget to say this is on CM3+. I hope you get this solved.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/690#issuecomment-803641900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOISR2GTSVWIEK7A2SJRRZTTEY64RANCNFSM4ZPKACCA .

shawaj commented 3 years ago

Copying in @mmilann here

@Jamos1988 do you have another Pi with nothing connected that you can try flashing the firmware with on a clean copy of RasPi OS?

Jamos1988 commented 3 years ago

Yes, I have a spare one. I'll also try on the existing cm3+ without sensors. Hope 0x41 will be detected as now it is not anymore.

Jamos1988 commented 3 years ago

On both the CM3+ and a fresh 3b+, when starting up with cw3 bootloader mode, the Pi's will keep rebooting somehow. Ill keep trying.

Jamos1988 commented 3 years ago

Now it booted, however without pressing cw3. Now i2c address 0x41 appear, but still stuck at flash:

image

I can't remove the sensors on the system of this latest screenshot, so I will keep trying on the other pi.

Jamos1988 commented 3 years ago

Got it booted on a separate pi, cleared some UU drivers from config.txt and rebooted. Now I am in a never ending reboot cycle. It doesn't appear to have anything to do with using sw3 or not. I can't get the Pi's to boot anymore if the Pijuice is connected. Even on a clean system that doesn't have any of the software installed.

Edit: rebooting seems to be caused by hdmi connected, it draws to much power it seems early when the pi is booting. Letting it boot and then connecting hdmi sometimes will get me success.

Jamos1988 commented 3 years ago

Clean system, no sensors, bootloader mode with sw3, same problem:

image

I'll try a lower firmware maybe that's the problem. Edit: 1.4 also same problem

mmilann commented 3 years ago

@tvoverbeek possibly can be pijuiceboot problem, it is not block read/write but basic byte by byte access and prior access can contaminate I2C buffer. Also other possibility is timing there are delays between transactions and I can suspect that newer kernel can have different timing. If possible @Jamos1988 to try with some older debian Linux images.

Jamos1988 commented 3 years ago

@mmilann which image do you propose? Where can I get an older one? Also, @tvoverbeek suggestion is not doable then?

mmilann commented 3 years ago

@Jamos1988 here you can find older Raspbian to try pijuiceboot with: https://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2017-07-05/

Jamos1988 commented 3 years ago

That one will not boot or give hdmi signal for some reason on a 3b+ will try another one. Will tvoverbeeks solution not be advisable to try as something extra or will this definetely be a no go?

mmilann commented 3 years ago

One note about manual bootloader start, do not run i2cdetect or similar commands before you run pijuiceboot because that can initiate pijuice to exit boot mode.

pijuiceboot i c program and for this suggestion it requires to update (remove start bootloader code) and recompile it.

Jamos1988 commented 3 years ago

How do I update and recompile? Any hints? :😊

On Tue, 23 Mar 2021, 16:55 mmilann, @.***> wrote:

One note about manual bootloader start, do not run i2cdetect or similar commands before you run pijuiceboot because that can initiate pijuice to exit boot mode.

pijuiceboot i c program and for this suggestion it requires to update (remove start bootloader code) and recompile it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/690#issuecomment-805019397, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOISR2ASSAZR3MMZKTCL2GDTFC2WNANCNFSM4ZPKACCA .

tvoverbeek commented 3 years ago

@Jamos1988 Get the source from github (https://github.com/PiSupply/PiJuice/blob/master/Firmware/pijuiceboot.c). Make the edits and build it with gcc -o pijuiceboot pijuiceboot.c Since you are using a Compute Module I assumed you know how to compile and link a C program.

Jamos1988 commented 3 years ago

So, to summarize:

sudo nano pijuiceboot.c comment out the 2 write commands on lines 935 and 939 remove start bootloader code by commenting out line 49 and rebuild pijuiceboot by gcc -o pijuiceboot pijuiceboot.c

Right?

Tried that and:

image

Sorry, typo, needed gcc -o pijuiceboot pijuiceboot.c Will comment test results under here

tvoverbeek commented 3 years ago

Not pijuiceboot by .... but just: gcc -o pijuiceboot pijuiceboot.c The modified executable will then be in the current directory. Run with './pijuiceboot 41 firmwarefile`. Note 1 the leading ./. This forces the version in the current directory and not the originally installed version Note 2 Try using address 41, not 14

Jamos1988 commented 3 years ago

This is after editing correctly with gcc -o is this ok?

image

Then proceeded to try and restore line 49, so now result is:

image

Needed sudo for it, I can see by the edit date the executable is now edited indeed.

After this retried:

image

tvoverbeek commented 3 years ago

Last line executed fine. SO you should have a pijuiceboot executable with todays date in ~/PiJuice/Firmware. Note: The start() function (which uses START_BOOT) is never called. The 3 calls further down are all commented out in the source.

Jamos1988 commented 3 years ago

Ok, it didn't work. Rebooting the Pi just to be sure that I didn't run i2cdetect like milan suggests.

Jamos1988 commented 3 years ago

Still not working, error receiving data -1

Jamos1988 commented 3 years ago

Might be a weird idea, but I can give you RDP access through Anydesk might be faster for you to look at the files if you want.

Jamos1988 commented 3 years ago

Code executed successfully on a clean pi! Will now test the rest, see if behaviour normal after reboot.

Jamos1988 commented 3 years ago

Working again! Must say, I really don't know why this wouldn't work on my other image, so I hope you can give me some pointers on how I can fix this in my current image.

It succeeded on the first version you'll get with the raspberry pi disk imager "raspberry pi os 32 bit". Can you tell me how I can possibly fix this on my other image, so I can flash Pijuices in the future with that OS? Do I need to compare kernel versions? Or could it be dependency issues? This is the only thing standing in the way of our decision to go for the Pijuice in our product indefinetely.

Hope you can support a little bit in this so I can fix my current image, so it is ready for Pijuice firmware flashing.

tvoverbeek commented 3 years ago

What version of pijuiceboot did you use (the original one or the modified one)? On adderss 41 or 14? Or did it work directly via the CLI/GUI?

How much work is it to make your working Raspberry Pi Os to your production image (i.e which software and/or packages to add)? If possible I would go this way, since you start from a working image.

Jamos1988 commented 3 years ago

I used the modified one without 935 and 939, but left the rest default. And did it with 41. I'll have to look into the clean image to see what needs to be done extra, might be doable. And a chance to start from scratch and know there is no clutter.

On Wed, 24 Mar 2021, 18:42 Ton van Overbeek, @.***> wrote:

What version of pijuiceboot did you use (the original one or the modified one)? On adderss 41 or 14? Or did it work directly via the CLI/GUI?

How much work is it to make your working Raspberry Pi Os to your production image (i.e which software and/or packages to add)? If possible I would go this way, since you start from a working image.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/690#issuecomment-806028158, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOISR2AI4KER6UJRDYLTBWTTFIP6TANCNFSM4ZPKACCA .

tvoverbeek commented 3 years ago

Thanks for the info. Just to state the obvious (?): The modified version of pijuiceboot only works in the case of a (partially) erased firmware. The 'normal' pijuiceboot requires that the firmware still recognizes the 'start bootloader' command on the default pijuiceboot I2C address (0x14). Note that you can change the default I2C address if needed. In that case use the changed address.

Will try to update the firmware README with this info for a bricked PiJuice.

Jamos1988 commented 3 years ago

Thank you so much for the great support and the great product!

On Wed, 24 Mar 2021, 20:15 Ton van Overbeek, @.***> wrote:

Thanks for the info. Just to state the obvious (?): The modified version of pijuiceboot only works in the case of a (partially) erased firmware. The 'normal' pijuiceboot requires that the firmware still recognizes the 'start bootloader' command on the default pijuiceboot I2C address (0x14). Note that you can change the default I2C address if needed. In that case use the changed address.

Will try to update the firmware README with this info for a bricked PiJuice.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PiSupply/PiJuice/issues/690#issuecomment-806086636, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOISR2EAHOE5BW2OWXZD2JLTFI23JANCNFSM4ZPKACCA .

mmilann commented 3 years ago

Now release pthon version of pijuiceboot tool for testing: https://github.com/PiSupply/PiJuice/blob/master/Software/Test/pijuiceboot.py

With option "--no_start" it will skip bootloader start command. This will probably be in next software package as more portable and easier to maintain replacement for current pijuiceboot tool.

tvoverbeek commented 3 years ago

@mmilann I am a bit confused about how this version works. WIth the --no-start option you use the existing I2C address (sys.argv[1], usually 14) to enter the boot loader. All following commands are sent to address 0x41. Without the --no-start option all commands go to address 0x41 (case of bricked firmware) Is that how it is supposed to work?

mmilann commented 3 years ago

@tvoverbeek with "no_start" option it will not call StartBootloaderI2C supposing bootloader on mcu side is already running and visible at address 0x41 so calling StartBootloaderI2C will not confuse mcu bootloader to exit.

tvoverbeek commented 3 years ago

@mmilann Thanks. Now I understand. I did not realize that when the bootloader is active it only responds to 0x41.

@shawaj By the way this python version also solves the 64 vs 32-bit version. Will try to integrate the pijucie_cli/pijuice_gui wrapper functionality into pijuice_gui.py and pijuice_cli.py. That way we only need 1 package version for both 32 and 64 bit.

thesteg commented 3 years ago

Not sure if it's related but I've been having loads of issues with pijuiceboot and the stm bootloader, it appears that the bootloader selectively decides if you can block erase which is odd and the behavior is echoed with stm32flash. I've now written a script that uses stm32flash utilising the bulk erase instead.