n_Reset line is activated on boot. It should not be active in my opinion because it cause massive problem. I control machine by using GPIO on IoT card. Machine turns on boot for one moment because n_Reset (GPIO6) is active. Is it possible to make n_Reset (GPIO6) deactivated on boot?
Hi there,
Could you clarify what the problem it’s causing? I don’t recommend changing the nReset timing on startup as other peripherals rely on this signal as well.
BR,
Chris
Hi Chris,
We produce Universal Converter. We have got 4 GPIOs on the board. When FX30 is booting we cannot control GPIOs (of course). All GPIOs are in high state then. One GPIO turns ON/OFF machine. When FX30 booted, machine started automatically without control. We advised our customer to invert logic, however it is not ideal solution, because n_reset line and GPIO is in low state for 100ms during booting (most of the time is in high state but 100ms is in low state) and machine starts anyway. Please look at screenshot from oscilloscope:
Blue line - n_reset line,
Yellow line - GPIO line after tristate buffer.
1 - FX30 power on
2 - after 9-10 sec we have got reset (low state) - time 100ms
3 - Finish booting. Our program starts (we can control n_reset).
4 - We change n_reset line
We have tested our solution on mangOH green, and everything is spot on mangOH green, because n_reset line is not active when device is booting so we have got 0V on GPIOs. When our program starts we activate n_reset line and everything is perfect. It is the purpose of n_reset line, right?
It is critical for our customer. Machine starts without control and can hurt someone. Our customer can use mangOH green of course, we can create delay mechanism, etc. But we think FX30 should not have n_reset line active on boot.
Is it possible to deactivate n_reset line on boot?
Best regards
Bartek
Hi Bartek,
My concern with using GPIO6 as you are in 3 and 4 is that hardware peripherals such as the USB hub, ethernet controller and GPIO expander are being brought in and out of reset.
Are you trying to hold your card in a reset state? I’m still not clear on your setup, but is it possible to delay turning on your machine via the GPIO that controls power?
You could also try setting this AT command, but I’m unsure if the 100ms pulse will be removed:
AT+WIOCFG=6,4
Please be aware if you do execute this command, do not use the RMARESET command as there’s a known issue that will brick your device.
BR,
Chris
Hi Chris,
I want to hold card in reset state on boot and activate the card manually by my program. Yes we can create mechanism to delay turning on the machine but it is ugly solution. We would have to be sure that booting time is always the same. Who can guarantee, the time will be always below 1min? We would have to add another electronic board to delay the machine (another cost). It is serious problem of FX30 and it should be corrected ASAP. I have crated the same topic on Legato forum. Please read Dave POST . I am not only one person who thinks (I do NOT think I KNOW) it works incorrectly.
The command AT+WIOCFG=6,4 has bricked my FX30. Do you know how where can I find documentation for AT+WIOCFG?
Best regards
Bartek
Hi Bartek,
Sorry for the trouble. To recover you unit, please follow this procedure:
-
Follow the steps in this posting to bring the unit up in boot and hold mode:
[fx30] Bricked after AT!RMARESET=OEM (USB device not found) -
Download the stock WP module R13.1 one-click executable:
https://source.sierrawireless.com/~/media/support_downloads/legato/wpx5xx/release%2013.1/combined%20images/wpx5xx_release-13.1_generic_exe.ashx?la=en -
Run the tool and ensure the firmware updates
-
Log on to the FX30 and change AT+WIOCFG=6,16
-
Now, update the FX30 firmware onto your device
Let me consult internally about the 100ms pulse. I suspect this isn’t FX30 specific but I’ll get back to you.
BR,
Chris
Hi Chris,
Thanks for info. I will try to un-brick my units tomorrow.
100ms pulse is not main problem (of course it will allow us to invert the logic). But main problem is n_reset line.
You have seen screenshot from oscilloscope. n_reset line on FX30 are in high state on boot and everything on IoT card works without any control on boot.
I checked n_reset on mangOH green - n_reset line is not active on boot. It prevents from unintentional behaviour. I activate n_rest after boot and gain control on IoT card.
I checked n_reset on mangOH red - n_reset line is not active on boot. Again, it prevents from unintentional behaviour. I activate n_rest after boot and gain control on IoT card. I do not have screenshot from oscilloscope, but I have taken photo when mangOH red was on boot. As you can see green LED is on - GPIO is active, but I have got 0V on my multimeter. When I activate n_reset line, multimeter shows 1.8V. It is save solution.
I wanted to inform you, if someone used FX30 to control machine right now, it would be against EU law.
Please read Machinery Directive EU (Points 1.2 Control machine)
“Control devices must be designed or protected so that the desired effect, where a risk is involved, cannot occur without an intentional operation” - FX30 cannot cover it.
Please do not try to convince me that everything is fine with n_rest line on FX30, because is not.
It is second massive difference between managOH units and FX30:
- RTS/CTS line is on IoT cards, on mangOH green and red. FX30 does not have RTS/CTS line on IoT. We could not relay on RTS/CTS when we were designing new IoT because it would work on mangOH units not on FX30.
- n_reset works correctly on mangOH units, but incorrectly on FX30.
Please consult internally issue with n_reset line. 100ms pulse is nothing compering n_reset problem. And please pay attention to differences between FX30 and mangOH units
Best regards
Bartek
Hi Bartek,
The 100ms pulse is present on the WP8548, so it’s not limited to the FX30. The reason you don’t see the issue on the mangOH boards is that GPIO6 is gated.
Please keep in mind the mangOH boards are designed as prototypes for development so they typically have extra buffering and multiplexers. The FX30 design routes the POR signal to the IOT slot without gating the signal. I apologize for the inconvenience, but this was a design decision for the product.
Regarding the UARTs, the mangOH Green supports many UARTs because there is additional UART hardware (multiplexers). The mangOH Red only supports UART1 which routes to the IOT card.
Comparatively, there are 2 FX30 variants: The FX30 ethernet version, which routes UART2 to the IOT card slot. And the FX30S (serial) version, which routes UART1 to a DB9 connector and UART2 to the IOT card slot to match the ethernet version.
The WP module has 2 UARTs:
UART1 is an 8 pin UART according to the technical specification, but actually only supports 4 pins
UART2 is a 4 pin UART, but actually only supports 2 pins
I agree there is a known limitation with RTS/CTS on the FX30/FX30S.
I’m sorry I don’t have a better answer for you.
BR,
Chris
Hi Chris,
GPIO6 on mangOH units are used for low power reset not for n_reset. n_reset signal goes through multiplexer on mangOH green but not on mangOH red. Difference between n_reset on mangOH red and FX30 is only GPIO number. n_reset on FX30 is controlled by GPIO6, on mangOH Red by GPIO2.
You do not have to apologise for bad decision someone made ( I feel it is mistake. You design n_reset line and your final product does not use it, it causes problems… ) This is inconvenient/problem for all customers not only form me. We produce IoT cards and we have got direct contact with end users of FX30. Usually n_reset it is not an issue, sometimes it is small inconvenient. It is serious problem, in last project.
Line RTS/CTS is inconvenient for us because we cannot use RTS/CTS line in generic IoT product.
Anyway, many thanks for everything Chris.
Best regards
Bartek
Hi Chris,
Your solution to un-brick FX30 does not work. Any other ideas?
Best regards
Bartek
Hi Bartek,
Could you please provide the details on the steps that failed? I’ve tested the procedure myself, so I’m confident they work.
From the photo, it looks like you have the test point permanently held to ground. However, once the DM port is up and the module has booted the first time after being bricked, please release this line from ground, otherwise the WP module will always boot up in boot and hold mode.
BR,
Chris
Hi Chris,
I don’t hold point permanently to the ground. DM port is never up, it is my problem. I release line from the ground anyway, no success.
I know, the procedure works, because I bricked and un-bricked another FX30. Maybe there is something wrong with EEPROM?
Best regards
Bartek
Hello Chris,
I am unfortunately in the same situation. Reading the thread, I see that it is the same command (AT+WIOCFG=6,4) that bricked my Fx30. I was trying all possible options to keep the gpio6 (n_reset) low during the power up sequence.
I tried the manipulation you propose to unbrick the unit but as for Bartek it does not seems to work on this situation.
Here is step by step the operations I performed:
- Soldered a wire to the test point indicated
- Connect the wire to the ground
- Connected the USB port to my PC
- Powered up the Fx30
My PC never detects new USB ports.
If at that point I disconnect the wire from the ground nothing changes.
Running the download executable you provided always ends up in failure to detect the modem.
By the way, my RED LED is now blinking (with the test point wire connected to ground or not).
Thanks for your help. Christian.
Hi Bartek, Christian,
Could you please confirm:
-
Are you holding the wire to ground for long enough? I usually use a Windows machine with the Device Manager open. I power on the FX30 while holding the wire to ground and wait until I see the DM port come up, under the Ports category in the Device Manger
-
Are you connecting using Windows machines? If so, please ensure you’ve installed the latest Windows drivers from the Source:
https://source.sierrawireless.com/resources/legato/drivers-for-wp75xx_wp76xx_wp8548-series-modules---latest-release/ -
If you’re using Linux, you can check if the ports are up by checking /dev/ttyUSB*
Also, use the latest version if swiflash:
https://source.sierrawireless.com/resources/airprime/software/swiflash/
BR,
Chris
Hello Chris,
I have been running the operations as you describe it.
- Test point connected to the ground
- USB cable connected to the PC
- powering-on of the Fx30
- the SWI elements never appears on the “ports” category of the Windows Device Manager.
I was having an older version of the Windows drivers. I uninstalled then, rebooted the PC, then installed the new version. The result is still the same.
Any other suggestion will be welcome.
Regards, Christian.
Hi Christian,
Hmm, I’m not sure why you’re not seeing the DM port come up. Do you see any other elements under Ports come up?
Could you please double check your connection to the TP and ground? This process is very reliable and it typically only fails when the connection is not made properly.
BR,
Chris
Hello Chris,
No port is coming up during this manipulation.
I double checked the connection to ground it. It is good.
Regards, Christian.
Hi Christian,
I’m sorry, I don’t have any other ideas to try on your bricked unit.
Do you have another working FX30? Could you try this TP to ground procedure on a working board, just to ensure it’s being done correctly?
BR,
Chris