PWM stability issues (resetting)

RE: PWM stability issues (resetting)

stellar7 — Thu, 02 Aug 2018 00:33:53 GMT

oh, the motor draws over 100ma, but it's not being powered by the chip, the chip is controlling it via an h-bridge. I get roughly a max of 5.8ma total on the nrf52832 and bridge when running.

RE: PWM stability issues (resetting)

Einar Thorsrud — Wed, 01 Aug 2018 13:34:26 GMT

This is probably due to difference in internal resistance of the GPIO pins which can vary a bit (also between chips).

I suggest the following approach to fix this issue:

Determine the maximum current consumption of the motor (typically when it starts).
If the maximum current consumption is lower than the IOH,HDH, then you should be OK by just configuring the pin as high drive. Remember to use the minimum value (6 mA) so that the value is valid for any nRF52832 device, as there can be significant variation.
If the current consumption of the motor is higher, then you need to use a form of buffer so that you can supply the motor separately and not via the nRF52.

RE: PWM stability issues (resetting)

stellar7 — Wed, 01 Aug 2018 03:46:09 GMT

I'll add--the weirdest part is that with some pin outs, it immediately resets. For example, when using pins P0_12 and 13 for forward and reverse it will either immediately reset when controlling the motor or run for about 2 seconds. However, when using pins P0_11 and 14, it rarely resets--usually running for several minutes.

RE: PWM stability issues (resetting)

Einar Thorsrud — Mon, 30 Jul 2018 08:57:25 GMT

I see. Since you only see this with the motor connected, then I think we can say with high certainty that the reset is actually due to a BOR, and that you need to revise your HW to prevent the supply voltage from ever falling below 1.7 V. You would need to get hold of an oscilloscope or similar to say for sure, though. (A multimeter is not sufficient, as the voltage drop might be very short in time.)

RE: PWM stability issues (resetting)

stellar7 — Fri, 27 Jul 2018 17:19:55 GMT

It's possible. Unfortunately, I don't have an oscilloscope. You're correct that it doesn't reset when the motor isn't connected. I've watched the nrf52832 pin outs with a logic analyzer and they look good... and the h-bridge output with a multimeter and it's what I would expect.. But yes, without an oscilloscope I can't know for sure about the voltage dropping too low (I see the voltage drop from 3.3 to roughly 3.2 on the meter). Thanks for your suggestions.

RE: PWM stability issues (resetting)

Einar Thorsrud — Fri, 27 Jul 2018 07:32:44 GMT

Perhaps the reset reason really is brown-out, as indicated by the RESETREAS register? I don't know anything about your HW, but could it be that when the PWM signal causes the motor to run, the increased current consumption causes the supply voltage to drop below the minimum supply voltage (1.7 V)? Have you tried to meassure the supply voltage for the nRF52832 using an oscilloscope to see that it never drops below 1.7 V when you control the motor? Also, you could test and see if disconnecting the motor will prevent the resets.

RE: PWM stability issues (resetting)

stellar7 — Thu, 26 Jul 2018 14:37:12 GMT

I mean, I'm getting log data from RTT... I added the segger code and am only getting additional lines for the segger statements. When the chip resets, I have to reconnect RTT, and I see initialization info and still 0 for resetreas (he's some output)...

0> ###### Testing SEGGER_printf() ######
0> <info> GPIOTE: Function: nrfx_gpiote_init, error code: NRF_SUCCESS.
0> <info> GPIOTE: Function: nrfx_gpiote_in_init, error code: NRF_SUCCESS.
0> <info> GPIOTE: Function: nrfx_gpiote_in_init, error code: NRF_SUCCESS.
0> <info> pwr_mgmt: Init
0> <debug> nrf_sdh: State request: 0x00000000
0> <debug> nrf_sdh: Notify observer 0x0003B8D8 => ready
0> <debug> nrf_sdh: State change: 0x00000000
0> <debug> nrf_sdh: State change: 0x00000001
0> <debug> nrf_sdh_ble: RAM starts at 0x20002A98
0> <info> app: RESETREAS 0

RE: PWM stability issues (resetting)

Einar Thorsrud — Thu, 26 Jul 2018 06:53:36 GMT

The reason I suggest this approach is that the device does not simply reset itself under normal situations, so it is likely that an error has been caught by an error check, and that the error handler is resetting the device as a consequence. From there, you can see what caused the error (file name, line number and error code) when you build the project with debug defined (-DDEBUG in your Makefile). See An introduction to error handling in nRF5 projects for details.

By default, most SDK examples use UART logging, but you can configure RTT logging (via a debugger) instead if you want in the projects sdk_config.h. You can see information about logger configuration here. Alternatively, if you struggle with logging, you can put a breakpoint in the error handler instead and read the relevant data (file, line, error code) from memory directly with the debugger.

RE: PWM stability issues (resetting)

stellar7 — Wed, 25 Jul 2018 13:21:18 GMT

First, thanks for the response. I changed to use -O0 -g3 and -DEBUG. I also found a reference to -DDEBUG and tried it as well--not sure which is correct. Should I be able to see the errors in RTT? Or will I have to attach a full debugger.. I'm just building with gcc and no real IDE.

If I do a soft reset, through the reset pin, I get 1 for RESETREAS .. and after a flash I see a 4, but still a 0 when it resets when running the motor.

RE: PWM stability issues (resetting)

Einar Thorsrud — Wed, 25 Jul 2018 12:26:07 GMT

Hi,

Typically, a reset is caused by an error caught by an error handler. The default error handler in the SDK will trigger a system reset unless DEBUG is defined for the project. Can you define DEBUG, enable logging and build without optimization and use a debugger to check the state of the system at the time of the error? It should give some indication of what went wrong.

Also, I would not expect the RESETREAS to be 0 after a reset. It should only be 0 after a brownout reset or power on reset, unless you clear it in your application before you read it.