FX30 n_reset line


#1

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?


#2

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


#3

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:

fx30-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


#4

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


#5

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


#6

Hi Bartek,

Sorry for the trouble. To recover you unit, please follow this procedure:

  1. 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)

  2. 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

  3. Run the tool and ensure the firmware updates

  4. Log on to the FX30 and change AT+WIOCFG=6,16

  5. 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


#7

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:

  1. 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.
  2. 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