I am having this problem after updating to R15 removing power for a longer period and re applying power allows it to continue i have not been able to determine the root cause yet.
Is the modem firmware SWI9X15Y_07.12.14.00 compliant with the Linux distribution SWI9X15Y_07.12.09.00?
Or do I need to update everything including rebuilding the Legato?
I had hard coded the I2C speed to 400khz this is not recommended and broke things badly from R14 to R15 i have reverted this change and was able to rewrite the bits of code that was relying on high speed I2C.
We’re seeing this issue on release 14. I’m optimistic release 15 will solve this, however release 15 is blocking us in another way.
When installing our system update, avcDaemon fails when trying to load libssl.so.1.0.0. I checked out the library folder and release 15 only seems to include libssl.so.1.0.2. Looking for advice on how to solve this. I know @dfrey mentioned a migration from openssl to tinydtls. I’ve tested this with Legato 17.11 and Legato 18.02.
I seemed to solve the above libssl.so.1.0.0 issues by ensuring my toolchain was up to date (thanks @dfrey) . Unfortunately release 15 of the firmware does not seem to solve MCU/GPIO related issues.
So far we’ve witnessed this bug occur on a seemingly random basis. It will sometimes run for hours without issue and then suddenly re-appear. Sometimes it will even do it from boot.
This issue is a really huge blocker for us (and most MangOH users I suspect). My best guess is that the MCU is causing this problem, but it’s difficult to diagnose something that’s closed source.
@nick, @mrjoso, could you provide any more details on the scenario (mainly timing)? We’ve been stress testing GPIO and ADC access with Release 15 and have not encountered this issue. Are you both seeing the issue manifested the same way, with the I2C “Bus still busy”, etc messages? When the issue occurs, I would expect the I2C bus is locked up - so other MCU accesses like /sys/module/swimcu_pm/firmware/version or ADC reads would also fail. If you have other I2C devices, I would suspect those are also blocked.
@mrjoso, you mentioned that devMode is stopped - does this only happen if that is stopped?
This is correct, other i2c devices are blocked. I can’t provide any further timing details. It’s completely random. Sometimes it will work for hours, sometimes it fails right at boot.
Thanks Nick. Sorry, regarding timing, I meant the timing of the GPIO accesses while the system is running as expected. I just had a few more questions from another developer, as we’re going to try to reproduce this: (1) Is this on Red or Green? (2) external power supply or USB power, (3) Is the modem turned on, and active, (receive/transmit data) during the test?
We have not been accessing MCU GPIO pins very much since we require edge detection. I believe we use a few of them as outputs. The outputs work as expected when the i2c bus is not locked up. When I tried detecting edges with a polling loop, the i2c bus locked up pretty fast.
I’m sorry, currently I can only provide details with Release 14.
I have detected the problem when the devMode was stopped and MangOH Red Board was powered from the battery.
I’ve been testing on a custom firmware build based on the ingredients from release 15 for the WP85. The hardware setup we’re using does not include the wm8944 audio codec, so I removed the code that probes for this peripheral (in the Yocto image). I have yet to see this issue re-surface, so I’m cautiously optimistic. I’ll post again as soon as I have any new information.
Edit: Spoke too soon, seems to be back on one of my units.
I’ve been doing some thinking about the origin of this problem… and I have a few questions (mostly regarding the MCU):
Does the MCU communicate with any other peripherals on the board (aside from the WP85 over i2c)?
Is the wm8944 audio codec used for anything aside from audio?
Could the pca954x i2c hub play a role in mitigating this problem (and we see it more often because we don’t have an i2c hub)?
Is it possible this is related to the host PC communicating over micro USB? I saw this issue yesterday on one unit, and then suddenly every unit I connected exhibited this problem.
(Follow up to 4) I have not used the devMode app, but to my knowledge it controls power settings that are useful for development. Is there a setting in here I should check?
Why is the MCU firmware closed source and under what circumstances could it become open source? In all honesty I would probably have a difficult time working with the MCU firmware code, but debugging something open is infinitely easier. Debugging Legato is a dream because I can usually trace the problem line by line.
I cannot stress enough how much this is crippling our development at the moment, so any help is greatly appreciated.
Answer to each question below:
a. MCU is connected to Modem through i2c and couple of gpios. GPIOs from MCU goto the mangoh board
b. no.
c. Not likely.
d. Not likely.
e. it is used to allow the device not to goto sleep.
f. It is closed source as the liabiity of opening it up is very high.
As far as your particular problem is concerned, are you using a MCU gpio in high sampling mode? Why dont you use a different gpio?
Thanks for the details. We’ve already been working on using the MCU GPIO pins for low activity inputs/outputs, but that’s not really my main concern here. When this error occurs, all of our i2c peripherals become un-usable (including really mission critical ones like the accelerometer).