Advanced search FAQ Register Login

It is currently Tue Dec 12, 2017 5:46 am

 

Postby cocod17 » Wed Dec 06, 2017 4:57 am

Hello,

I am working with the UPS PIco HV3.0A board on the RPi. I have the i2c lines connected to another microcontroller to turn the RPi on and off via the i2c bus. I am able to successfully shut down the RPi and wake it up after a set amount of time. But the problem occurs shorty after the RPi board begins to boot up again after receiving the wake up call. During its boot up process the RPi seems to receive another i2c command and perform another file safe shutdown before completing its start up. I thought it may be the microcontroller but I removed the wires from the RPi after the microcontroller sends the command to wake it up from a sleeping state. I'm not sure where it is receiving this command from, any thoughts or comments would be much appreciated. Thanks in advance.

cocod17
n00b

Posts: 4

Joined: Wed Dec 06, 2017 4:48 am

Postby Dave » Wed Dec 06, 2017 9:14 am

GPIO_GEN27 is used to send a pulse train to the PICo - This lets the PIco know the Pi is still active and hasn't crashed. If this pulse train stops (and you have the gold reset pin installed) then the PIco will hard reset the Pi - Make sure nothing is interfering with GPIO27

GPIO_GEN22 is used to signal the file safe shutdown - When the PIco want's the Pi to shutdown safely it makes GPIO22 go HIGH. The PIco script running in the background monitors this pin and when it detects the pin going HIGH it runs the shutdown command. - Make sure nothing is interfering with GPIO22

The PIco doesn't use I2C to initiate the FSS, so if you are confident its being received over I2C then its nothing to do with the PIco.

Do you have a script running on boot to handle your own I2C shutdown commands? If so, disable the script and see if that is the cause. We have noticed that the I2C pins go a bit "funny" when booting... They aren't in a stable state so it could be triggering your shutdown script.

Dave
ModMyPi

User avatar

Posts: 1957

Joined: Wed Jul 22, 2015 11:36 am

Forum Administrator & Technical Support

Postby cocod17 » Thu Dec 07, 2017 3:35 am

Thanks for the reply Dave. I don't have any other wires coming out of the RPi, other than the GND (6), SDA (3), and SCL (5). The GPIO pins 27 and 22 are left untouched, as recommended in the user manual.

As for any scripts running on boot to handle my own i2c shutdown, there are none. I have one script run on boot to record video for a set amount of time and this is done using a cron job. I don't believe this to be the issue.

Is it possible that the original i2c command sent to the RPi during its sleep state is being stored somewhere and run again at a point when the RPi boots?

I attached my oscilloscope to capture what was happening during the boot process and see that there is a write followed by a read happening at address 0x68. And for some odd reason this same write and read process is done six times, with the same exact values. I don't write to or read from this address in my program for the microcontroller, so I am safely (hopefully) assuming that it is not coming from the microcontroller.

I seen that address 0x68 is the RTC address and is reserved by the UPS board. So is the RTC rebooting the RPi every time I send a software reset? If so, why would it send a command six times?
Again thank you for any insight you can offer.

cocod17
n00b

Posts: 4

Joined: Wed Dec 06, 2017 4:48 am

Postby Dave » Thu Dec 07, 2017 9:39 am

How does your microcontroller tell the Pi to shutdown if you don't have a script on the Pi? And how does it wake the Pi up?

Dave
ModMyPi

User avatar

Posts: 1957

Joined: Wed Jul 22, 2015 11:36 am

Forum Administrator & Technical Support

Postby cocod17 » Thu Dec 07, 2017 7:14 pm

The microcontroller is communicating to the Pi via I2C. In the documentation of the UPS PIco HV3.0A board the address 0x6B is used for the UPS PIco module commands, so then this becomes the address the master communicates to over I2C. Next, the register I wish to talk to is 0x00 since this controls the pico_state. And in this register I want to write 0xCC since this triggers the unconditional file safe shutdown. So, just like in the command terminal of the RPi I write,

sudo i2cset -y 1 0x6b 0x00 0xcc

to initiate a file safe shutdown. Then for my I2C data I have the following to be written,

uint8_t address 0x6b;
uint8_t data_written[] = {0x00, 0xcc};

This same command is used to shutdown and then start the RPi from a sleep state. As it should since the FSSD button does exactly the same thing.

cocod17
n00b

Posts: 4

Joined: Wed Dec 06, 2017 4:48 am

Last edited by cocod17 on Fri Dec 08, 2017 6:57 pm, edited 1 time in total.

Postby Dave » Fri Dec 08, 2017 9:25 am

Ahhh I see, ok you are communicating directly with the PIco. Makes sense :)

If you remove your microcontroller, and emulate the exact same steps by pressing the FSSD button on the PIco do you experience the same thing?

That will show if there is an issue with the PIco or not.

Dave
ModMyPi

User avatar

Posts: 1957

Joined: Wed Jul 22, 2015 11:36 am

Forum Administrator & Technical Support

Postby cocod17 » Fri Dec 08, 2017 9:34 pm

When I shut down the RPi with the FSSD button and then start it again with the button, I do not experience a random shut down during boot of the RPi as before. But I still do catch a write and read to address 0x68 with my oscilloscope, this is without the microcontroller connected on the I2C pins.

But the button would trigger a hardware interrupt so I don't think it is a hardware issue. My feeling is that it has something to do with the firmware, since it only happens during a software shut down.

The sequence that is caught on the I2C bus, without a microcontroller connected and using the FSSD button, is a write to address 0x68 with data 0x00. This is then followed by a read from address 0x68 with seven bytes returned. After further investigation, I see that these values could be reading back a time stamp from the RTC: seconds, minutes, hours, week day, month day, month and year.

What is odd about this is that I don't have the RTC active and in the documentation it shows the firmware has not implemented action based RTC yet. This is what leads me to believe it is a firmware issue.

cocod17
n00b

Posts: 4

Joined: Wed Dec 06, 2017 4:48 am

Who is online

Users browsing this forum: No registered users and 1 guest

Board index

The teamDelete all board cookies • All times are UTC [ DST ]