ST87M01 NB-IoT module — no AT response after wake sequence, requesting wake/power-up timing confirmation

[yashg25]

We're bringing up an ST87M01 module on a custom board and have not yet achieved a successful first AT command response. We've implemented what we believe is the correct wake/power sequence based on your EC-Lib reference source and a third-party open-source host library, but want to confirm we're not missing an ST87M01-specific requirement before we keep debugging on our end.

 

What we've implemented

• VBAT_DCDC_EN, NRESET (active low), WAKE_UP (active low) and RING are driven via a host-side I2C GPIO expander, not directly from MCU pins.
• Power-up sequence: assert NRESET high (out of reset), hold WAKE_UP idle-high, wait ~3 s settle, then pulse WAKE_UP low for ~100 ms and release it high.
• Separately, we also send a single \r byte over UART before each AT command (per the wake behavior we observed in ST87EC_Wrapper_WakeUp() in your EC-Lib reference), followed by a short settle delay before sending the actual command.

We're currently sending both the GPIO WAKE_UP pulse and the UART \r wake, since your own EC-Lib host HAL interface (st87ec_lib_hal.h) doesn't expose a WAKE_UP/PWR_ONOFF GPIO function at all — only ST87EC_Lib_Hal_DriveResetGpio() — which left us unsure whether the GPIO pulse is required on this interface or whether UART-only wake is sufficient and the GPIO pulse is redundant (or potentially harmful if done at the wrong time relative to the module's internal state).

What we've observed

• No response yet to a plain AT command sent after the above sequence (1 s timeout, no OK/ERROR/anything received).

On an earlier oscilloscope capture of the module's TX line (before any commands were sent from our side), we saw what looked like a periodic ~50 ms pulse roughly every 400–500 ms. We're not certain whether this is expected module behavior at that point (e.g. periodic network search/registration retry, or a boot-time pattern) or a sign the module hadn't actually left a low-power state.

My Questions: 

• For this UART interface configuration, is the GPIO WAKE_UP pulse required, or does the UART \r-byte wake alone put the module in a state ready to accept AT commands? If both are needed, is there a required ordering/timing relationship between them (e.g. GPIO pulse must complete before the UART wake byte, or vice versa)?
• Could you confirm the expected timing for the full cold-boot-to-AT-ready sequence (minimum settle time after power rail enable, minimum/maximum WAKE_UP pulse width, and expected delay before the module will ACK a UART byte)? We used ~3 s/100 ms/200 ms based on what we could find in public app notes, but don't have your internal timing spec to confirm these are correct.
• Is there any boot-time UART output (banner, URC, or similar) we should expect to see on TX independent of us sending anything, that would let us confirm the module itself is alive and out of reset, decoupled from whether our wake sequence is correct?
• Does the ~50 ms/~400–500 ms periodic TX pulse pattern we observed mean anything to you in isolation (i.e., without any AT traffic yet sent)?

Can you provide any other startup sequence which we can perform ?

Thank & Regards,
Yash Gupta

[Didier HERROUIN]

Dear yashg25,

To wake-up the modem, sending a character on the UART is enough, you don’t need to drive the wake-up GPIO (they have the same effect).

You will find the power-up timing inside the ST87M01 user guide (“§5.1 Power-Up”). The delay between the power supply rising (or the RESET if you drive it) and the DCDC_EN signal rising (indicating that VCORE is ok) is ~256ms. As you drive the EN signal, you should receive some URC messages from the modem after each reset (#REBOOT_RESET, #SIMST, ...). 

Remind that when you install the GUI, all the application notes and the user guide are copied on your PC and they are directly accessible from the GUI (button on the left).

Can you connect the GUI to check that UART works fine ? And which SIM did you insert ?
If a valid SIM is inserted, as soon as you supply the modem, it will check the SIM validity (#SIMST=1) and it will start band scanning (you can observe Tx pattern during this period, but the periodic Tx pulse you mention is different).

Finally, you mentioned that you connected VBAT_DCDC_EN on a GPIO expander. Do you mean DCDC_EN signal ? Indeed, this one indicates the state of the modem and it is an output.

Best regards,