I have a test fixture which performs a blinkup to a DUT and also has safety interlocks such as an E-Stop button and lid-latch. While the factoryBlinkup() call is executing (specifically while it is blinking) I am able to press the E-Stop button and release it while the IMP is still performing blinkup and the current test will continue as if the E-Stop had not been pressed at all. In other words, it appears that hardware interrupts are disabled during the factoryBlinkup() execution. Is this true? If so, is there any way around this so that a pin state change can still be detected during the blinkup and subsequently stop the test, or at a minimum just allow me to see that the pin state changed during the blinkup so that I can stop the test after the blinking has complete even if the E-Stop had been released again?
Under normal conditions if either the E-Stop or Lid-Latch change state and are no longer met, their corresponding interrupt callback is called (onPress/onRelease) and our current running test is cancelled immediately. While these interlocks physically cut power and still meet safety requirements this way, we are not supposed to allow a test to continue once the E-Stop has been pressed, even if released again a few seconds later. This same scenario can happen with our lid-latch interlock if opened and closed again within a few seconds during blinkup. Both are using GPIO on an IMP005 and are hardware interrupt capable.
Correct, the factory blinkup is blocking (as it bit-bangs the IO for consistency) - this hasn’t been an issue for customers before so it got left as-is.
I would have expected the pending IO change IRQ to have been queued in this case though, and would expect it to trigger when the factory blinkup call completes. What you might be seeing is the button library hiding this as it thinks it was a bounce; have you tried using the IO change handler direct?
I did manage to get it to queue up the interrupt callback so that it is detected once the factoryBlinkup has completed. However, in order to meet our safety requirements we need to be able to truly interrupt the blinkup so that we can prevent it from continuing even if the e-stop is released. Is there a way we can enable the hardware interrupts during the factoryBlinkup, or even poll a single pin so that if it changes state we can exit the factoryBlinkup routine? This is now a critical requirement so that our test fixture can be used.
As it stands, our only alternative would be to physically cut power to the fixture IMP005 with the e-stop during the blinkup, but we are very hesitant to pursue this route as we have “bricked” multiple IMP005’s by power cycling them while they were performing a blinkup and the only way to recover them is to re-cloudify with an OS image. This solution also would require a significant amount of work for our team to physically implement in the remote fixture.
It seems like cutting power is the best solution here (and arguably, the only option for a true safety critical emergency stop).
It should not be possible to brick an imp005 in this way, so we’d be very interested to know steps to reproduce that. Can you please file a support ticket with details?
We have high voltage running into our test fixture box and to meet safety requirements this power has to be cut in the event of an e-stop. We have a separate 12VDC power source which does not have to be removed in the event of an e-stop and this is what powers the fixture IMP. If we have to take a hardware solution approach, we would now also cut the 12VDC power to the fixture IMP since this would be the only way to guarantee the IMP resets the necessary remote relay pin that controls the high voltage source.
The problem that we are currently facing is that during the small ~5 seconds window during the blinkup process, the e-stop can be pressed, then released, and our high voltage will be returned to the fixture. Since the fixture IMP app code is suspended during the blinkup, that means that our e-stop is not detected in software by the IMP and we therefore cannot turn off the remote controlled relay which enables or disables the high voltage source. While the e-stop being in series with this high voltage source means physically we are safe in terms of cutting that power, we are required to not allow the high voltage power to be returned in the event the e-stop is released. Thus is our conundrum with the blinkup since the IMP is unable to change the safety relay pin state while the blinkup is occuring.
Is it possible for us to access the embeded linux OS on the IMP? We could perhaps then write a custom kernal driver or modify the blinkup to monitor the e-stop pin and change the safety relay pin accordingly.
I will also submit a separate ticket about the IMP005 bricking during blinkup. We have not had this occur for some time, but we also tend to avoid rebooting during blinkup so that we don’t run into it again. If we do the hardware change I described above, this will become much more relevant.
The imp does not run linux, it runs our in-house RTOS. The hardware is not capable of running linux, it’s more MCU-class - it will also not run any unsigned code, so it’s not possible for anyone aside from people with the HSM keys to make signed builds.
There may be a workaround here though. I’m checking if there’s an API you can call to retrieve a blinkup token which would allow you to simply not use the factory blinkup API and instead bit-bang the LED yourself whilst monitoring your e-stop.
Thanks for the clarification on the OS side. Just trying to pursue all routes possible.
That API call looks promising if we are able to get all necessary data needed for the blinkup and bit-bang the LED. This is something we would certainly be capable of doing. Please let us know if you find out this is possible.