nRF52832 IO problem

RE: nRF52832 IO problem

maxishev — Wed, 19 Jun 2019 08:52:28 GMT

The problem was that at power-up at some point the voltage at MSP flash was relatively low and it damaged the flash so it stopped working. This damage may be resolved only by FW update of MSP but no always.

At some point during our problem debug we thought that nRF have problem, and we also saw no good behaviour of nordic IO and thought that ot damaged. It is the reason I opened this tread here. But at the end the problem was with MSP and after MSP replacement the design worked again.

I would to recommend you to deassemble your nordic chip and check it at other board to ensure that it is it that damaged..

RE: nRF52832 IO problem

knowic — Wed, 19 Jun 2019 08:38:46 GMT

Hello,

Thanks for your information, Do you mean that MSP430 is damaged and nRF52832 is well in your board?

If it is , could you share us the reason? Now, with our board, it looks like the nRF52832 is damaged, and the module is ok.

Thanks again!

Jason Hu

RE: nRF52832 IO problem

maxishev — Wed, 19 Jun 2019 07:09:46 GMT

Hey

Yes, we solved it. We found that the problem was the second side of the communication - this processor was damaged. We sent our TI processors to manufacturers and they confirmed that they damaged and no Nordic microprocessors

Maybe it is also your issue. Test it.

RE: nRF52832 IO problem

knowic — Wed, 19 Jun 2019 07:01:52 GMT

Hello, sir

Have you fixed your issue? We have have similar issue, the TXD(P0.31) of nRF52832 looks like being damaged when connect to other module which operating at 3V level.

We make a 200pcs production with SMT, and found there are 15+PCS have the same issue(TXD damaged) after board function test. and we don't know others will fail or not in later work time.

thanks,

Jason Hu

RE: nRF52832 IO problem

maxishev — Sun, 10 Jun 2018 07:45:28 GMT

The problem with powering the 3.3V components from sensor is that the sensor don't have 3.3V pad so need to make connection straight from the sensor buck capacitor to board - that is no so good solution for high volume production.

About trying to put series resistors - we will try it

Thank you

RE: nRF52832 IO problem

hmolesworth — Thu, 31 May 2018 17:00:13 GMT

If MSP430 has 3.3 volts but the nRF52 does not the MSP430 Tx line powers up the nRF52 and could die. If the MSP430 3.3 volts disappears before the nRF52 3.3 volts the Rx line (from nRF52) powers up the MSP430 and could also die. Likely? Who knows, but series resistors in both lines provide some protection. The other alternative is to throw away the external buck and use the MSP430 3.3 volts for nRF52 as well, if it can handle total load.

RE: nRF52832 IO problem

maxishev — Thu, 31 May 2018 07:14:08 GMT

Really? The phantom power from near pin can move to other? Those two pins (RX and TX on MSP430) place one near the other at the chip.

RE: nRF52832 IO problem

hmolesworth — Wed, 30 May 2018 17:46:28 GMT

Hmm datasheet not much help; try capturing the three power rail traces above when power is removed. maybe there is some overshoot or ringing issue when the supplies collapse or the 9 volt overdrives the 3.3 volts.In anticipation of the result of this power-down test I should add that the series resistor would be required both in Rx and Tx, as either side can phantom power the other with sometimes catastrophic results

RE: nRF52832 IO problem

maxishev — Wed, 30 May 2018 10:18:47 GMT

The datasheet:

www.murata.com/.../product specification 1322 rev3 sca10h product datasheet eng.ashx

RE: nRF52832 IO problem

hmolesworth — Tue, 29 May 2018 19:02:53 GMT

I would start by reducing R49 until the nRF buck supplies 3.3 volts at the same time or earlier than the MSP430 3.3 volts. Ensure the nRF does not sink a lot of power until the 9 volts has stabilised by inserting a time delay at the start of main() to ensure this. That at least removes some of the potential issues. meantime do you have a link to a datasheet on the sensor?

RE: nRF52832 IO problem

maxishev — Tue, 29 May 2018 07:00:28 GMT

Instructors on the schematic are ferrite beads for noise filtering

RE: nRF52832 IO problem

maxishev — Tue, 29 May 2018 06:58:11 GMT

Here this screenshot again:

Yellow is 9V, green is nRF 3.3V and blue is on-sensor buck 3.3V

RE: nRF52832 IO problem

maxishev — Tue, 29 May 2018 06:55:07 GMT

1. Because of long delay between enable to booster and stable 9V (it is about 15 msec) and because short delay at 3.3V buck - less than 1 msec (you can see it at screenshot) we decided to drive enable to 3.3V from 9V and ensure they will rise at same time. At previous version of our board both - buck and boost was driven by charger. Here you can also to put attention that buck here also accept as input voltage - the power from charger. And only its enable is driven by 9V.

2. I can't show you what happening according to MSP430 because I don't have schematic of it. It is like black box for us and manufacturer of the sensor no published the schematic of it The only thing we know - the MSP430 get 3.3V from buck converter from 9V on sensor board. I shown before the relationship of 3.3V on-sensor and on-board.

RE: nRF52832 IO problem

hmolesworth — Mon, 28 May 2018 15:16:11 GMT

Deriving the 3.3V Buck from the 9V Boost is an unusual choice and is likely to be both inefficient and troublesome; if that choice was made for sequencing then it would be better handled by deriving both regulators from the charger with an alternative enable/disable method for sequencing. Focusing on the sensor can you show what happens to the 9V as I recall you posted the sensor was an MSP430 so the interesting part of the circuit is not shown; also I can't make out the inductor shown on the sensor, is that a feedthrough or a real inductor? It's difficult to see the connection.. the sensor schematic would clarify these questions.

RE: nRF52832 IO problem

maxishev — Mon, 28 May 2018 06:46:29 GMT

Here it is:

Charger accept 5V Vbus or 3.7V nominal from Battery if Vbus no connected. After it - this voltage boosted to 9V for sensor and then 3.3V created.

The waveforms for this power sequesting:

RE: nRF52832 IO problem

hmolesworth — Mon, 28 May 2018 00:40:03 GMT

I think a schematic is required so I can see the power sources and (more importantly) the power sequencing. You may be seeing back-drive, phantom power or simple spike damage. If the schematics are confidential maybe provide some secure access or post to Nordic engineers privately (I am not Nordic, just a freelance designer)

RE: nRF52832 IO problem

maxishev — Sun, 27 May 2018 09:38:24 GMT

Hello!

We tried also to use buffer at this signal. But after 2 weeks the sensor also get damaged.. What can be te reason that the IO still get damage?

Thank you

RE: nRF52832 IO problem

maxishev — Sun, 13 May 2018 12:48:00 GMT

After some running. tests and tries we found that our sensor still get damaged.. We put series resistor of 500 ohm on our signal that needed to bring maximum 6.6 mA to the IO - the current that MSP supposed to hold on.. Now we are running tests with buffers..

RE: nRF52832 IO problem

maxishev — Tue, 01 May 2018 14:48:50 GMT

Ok, it answer my question.

Thank you very much and to all that answered here to my problem.

RE: nRF52832 IO problem

hmolesworth — Tue, 01 May 2018 14:05:57 GMT

Personally I would use 1k Ohm; even a poor layout will probably have less than 20pF stray capacitance which gives a CR rise/fall of 20 nSecs. At 230400 baud that is not significant. Should the MSP430 not be on the same pcb then of course the capacitance is likely to be higher. 1k Ohm limits surge currents on mismatched power rails to 1mA. If this was a SPI interface at 8MHz then I would say use the level shifter.

RE: nRF52832 IO problem

maxishev — Tue, 01 May 2018 13:20:42 GMT

We run UART at 230400 baud rate.. So as you say - we need to use the buffer?

RE: nRF52832 IO problem

hmolesworth — Mon, 30 Apr 2018 14:21:17 GMT

I would suggest rather more than 102 ohm; assume worst-case 3.3 volts @ (say) 10mA limit indicates 330 ohms minimum. A more robust alternative might be to use something like SN74LV1T34 Single Power Supply Single Buffer GATE CMOS Logic Level Shifter. The resistor solution can limit maximum baud rate due to distributed capacitance, although I would imagine you are not above 115,200 in which case 330 ohm is fine.

RE: nRF52832 IO problem

maxishev — Mon, 30 Apr 2018 06:52:56 GMT

[quote userid="65515" url="~/f/nordic-q-a/32798/nrf52832-io-problem/130207"]Looks like a classic phantom power issue, which I mention earlier in this thread, given the MSP430 powers up long before the nRF SoC. If there are other devices attached (host MCU or external serial port to PC etc) care is required to ensure no port pins are driving into the nRF52832 SoC during a power-down period. In a simple system with a host MCU typically a UART Rx, Tx and the nRF52832 SoC RST pins will be connected between host MCU and nRF52832 SoC. In that simple case either Rx or Reset pins will phantom power the entire nRF52832 SoC if they are left driven high while nRF52832 SoC power is removed. This is perhaps not unexpected if we assume dual internal schottky diode protection (a clamp diode to both GND and VCC) instead of single internal schottky diode (to GND with low breakdown voltage). This means that to power-down the nRF52832 SoC the MCU code must first drive both UART RX and BLE RST pins low, otherwise the supply of (say) 3 volts only drops to 2 volts or so when the supply is switched off and the nRF52832 SoCtherefore does not reset.
In a similar manner, connecting a typical FTDI USB serial port to the nRF52832 SoC can unexpectedly phantom power the part, and stop it correctly resetting or powering down unless the FTDI is first removed. This can cause confusing and unexpected behavior. There is an excellent Dialog publication Training_07_DA1458x_prototype_bring_up_guide _Training_07_DA1458x_prototype_bring_up_guide -v1. 2I 2I_ which actually touches on this without mentioning why:
It is recommended that P0_4 and P0_5 are made available for UART communication during production test and board bring-up. Note that, if the two pins are also used as interface to an external MCU, that this MCU will need to be able to high-Z the pin connected to P0_5
The reason is that resetting the test board doesn't work correctly unless drive to the Rx pin is first removed, including drive from any connected FTDI USB serial port or driving low or floating any connected host MCU.[/quote]

We now making tests to put series current-limit resistor. With 51 ohm it still got damaged, and with 102 ohm it seems to survive, but we will test more. We are running power-on/power-off tests that power on and off the board every 8 seconds, For now board with sensor and series resitors run 1 week and looks good. When at the past it was damaged after 1-2 days. And with 51 ohm it run 4 days.

So maybe this is really the solution that we need

Thank you

RE: nRF52832 IO problem

maxishev — Mon, 30 Apr 2018 06:40:20 GMT

I touch with oscilloscope the TX pin on MSP430 package and see that it no transmit anymore when it damaged.

Here the screenshots of UART IOs and supplies that we already did:

This is power-up (with 100k pull-up resistor on TX):

Yellow - 9V, green - 3.3V, pink - RX, blue - TX (IO that get damaged)

This is power-down:

And yes, I put scope on IO of MSP and see transmission when the chip works ok. And don't transmit data when it no.

RE: nRF52832 IO problem

hmolesworth — Sun, 29 Apr 2018 16:48:09 GMT

Looks like a classic phantom power issue, which I mention earlier in this thread, given the MSP430 powers up long before the nRF SoC. If there are other devices attached (host MCU or external serial port to PC etc) care is required to ensure no port pins are driving into the nRF52832 SoC during a power-down period. In a simple system with a host MCU typically a UART Rx, Tx and the nRF52832 SoC RST pins will be connected between host MCU and nRF52832 SoC. In that simple case either Rx or Reset pins will phantom power the entire nRF52832 SoC if they are left driven high while nRF52832 SoC power is removed. This is perhaps not unexpected if we assume dual internal schottky diode protection (a clamp diode to both GND and VCC) instead of single internal schottky diode (to GND with low breakdown voltage). This means that to power-down the nRF52832 SoC the MCU code must first drive both UART RX and BLE RST pins low, otherwise the supply of (say) 3 volts only drops to 2 volts or so when the supply is switched off and the nRF52832 SoCtherefore does not reset.
In a similar manner, connecting a typical FTDI USB serial port to the nRF52832 SoC can unexpectedly phantom power the part, and stop it correctly resetting or powering down unless the FTDI is first removed. This can cause confusing and unexpected behavior. There is an excellent Dialog publication Training_07_DA1458x_prototype_bring_up_guide _Training_07_DA1458x_prototype_bring_up_guide -v1. 2I 2I_ which actually touches on this without mentioning why:
It is recommended that P0_4 and P0_5 are made available for UART communication during production test and board bring-up. Note that, if the two pins are also used as interface to an external MCU, that this MCU will need to be able to high-Z the pin connected to P0_5
The reason is that resetting the test board doesn't work correctly unless drive to the Rx pin is first removed, including drive from any connected FTDI USB serial port or driving low or floating any connected host MCU.

The MSP430 port pin may not survice powering up the entire nRF Soc; if you can't stop the MSP430 line driving to the nRF then perhaps add a series current-limiting resistor.