BC660 RESET_N line

IoT Modules LPWA Module
1

I am trying to debug a design that has the reset_n directly connected to the gpio line of a 3V3 powered micro controller.

On page 21 of the BC660_GL-Hardware_design it states that “The RESET_N / PSM-EINT has an internal design to prevent current backflow”
On page 27 it’s noted that the RESET_N ViH max. is 2.1V
We occasionally encounter that the BC660 isn’t reset. Is it possible that the microcontroller push pull output of 3V3 damages the RESET_N input?
I know the reference design recommends to place a transistor and to only pull the line low, but this is an existing design that occasionally gives issues (around 5% of the unit’s.)
If we force reset the BC660 once by connecting the RESET_N to GND with a wire, all starts to work normally. Even after a power cycle the microcontroller is capable of resetting the BC660

2

Do you use RESET pin as push-pull or open-drain? Proper use when connected directly to the MCU is to keep it floating and when you need to reset, just pull it to GND for a short while and then leave it floating again. Depending on the MCU floating means default, analog, not-connected etc.
Do not set it to high, because it will put 3.3V on the line and this can damage it.

3

Thanks for the answer. At the moment the MCU gpio lines are push pull. I already suggested to change them to input and “output low” to activate the input. I saw in the datasheets that the BOOT input is not having a “current backflow protection” circuit and it’s currently driven by a pushpull output as well. We further examined the issue and came to the conclusion that the problem is not that the BC660 isn’t resetting but it’s related to the baudrate setting. Somehow the AT+IPR=19200 is not recognised and due to that communication with the BC660 isn’t working as expected. I connected the BC660 to a pc and noticed that ocasionally the A was missing from the AT I was sending to the BC660. So instead of echoing AT OK it was just echoing T error. I still have to investigate further what might be causing this. It happened even after changing the baudrate to 19200.