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?
As far as I have been able to work out, the nRESET line on the FX30 IoT slot is pulled HIGH with a weak pullup in hardware. I haven’t found a way to force it the other way.
And yes, this is is breach of the IoT design guidelines, and I agree that this should not be happening.
I have got the same thread on Sierrawireless forum: n_reset line sierra . Thanks for answer.
Could you please point me to the IOT design guidelines you’re referring to? Are you referring to the IOT Technical Specification?
This is the doc I have been using: IoT Expansion Card Design Specification
Unfortunately I can’t find the notes in this version that said that the Host side of the IoT interface should hold the nRESET line low by default - it may have been in an earlier version of the doc. But if you look at the schematics for both the mangOH Green and Red reference designs you can see that is the way that they behave (except for the very early mangOH Green DV1 & DV2 boards).
Thanks for the link to the spec.
I’m concerned readers of this thread may be confused when you state the FX30 is in breach of the IOT design spec. The FX30 does have the nReset signal that holds the IOT card in reset upon power on and there is the capability for host applications to control the signal (although we don’t recommend it). So I would say it does not breach the spec but it was a design decision for the behaviour of this signal.
We do realize there are limitations with this design.
The mangOH boards can be used as a reference design however please be cautious when testing between against the FX30. The mangOH boards typically contain buffering and extra hardware that is suitable to evaluating WP modules. The FX30 is a certified commercial low cost product.
Yeah. I’ve been working with the IoT cards for a number of years now … the default Low probably came out of an early version of the spec in combination working with the mangOH family of boards.
But I’ve had another look through the spec - particularly with regards to the power-up process:
Section 3.7 indicates that the nRESET is brought HI as the host brings up the power rails for teh card.
But Section section 2.3.1 indicates the required power-up sequence - +5&+3V3 first, then the 1V8 (immediately after). I’ve never put a CRO on the power pins to see if the FX30 does it this way or not.
But … my view is the same as @TheGod - the IoT cards should be held in reset until the application or host explicitly brings them out. Stops the hardware equivalent of the ‘Flash of Unstyled Content’ seen on some websites.
It is a little bit funny. You said “We do realize there are limitations with this design.” and “…but it was a design decision for the behavior of this signal.”
in other words you said:
We know this is incorrect and should not work like that, but we did it on purpose, so it is fine
No, that’s not what I’m saying. I’m saying that we realize now, after you raised the issue on the forums, since you had difficulty to do what you wanted to.
Whether the FX30 design is correct or not, everyone is entitled to their own opinion. I’d like to mention again, that the mangOH boards and FX30 have very different design considerations. The mangOH is designed to be a flexible and quick to prototype solution. The FX30 is designed to be a commercial, low-cost, certified product. I suggest to design your IOT cards for the end product that your customers will be using. If both the mangOH and the FX30 are supported, then you will need to account for the differences between the hardware and software.
My goal here is purely to help you get through any technical issues.