PWM stability issues (resetting)

[stellar7]

I'm using: nrf52832, SDK 15.0, SoftDevice S132 v6.0.

I'm trying to control a motor using an H-Bridge. If I simply do a nrf_gpio_pin_write to set forward/reverse to 1/0 or vice versa, there is no issue. I can change motor directions quickly.

However, I want to control the motor speed as well. When I use PWM outputs to control forward/reverse, the system will crash/reset when I try to change the motor direction. I can add a delay in the code where, between changing direction, I set both forward and reverse to 0 and wait 600ms. When I add this delay, everything works, but I want to minimize or remove this delay (400ms in unstable, 500ms is mostly stable, 600ms is stable).

I've tried two different h-bridge boards with different chips (L9110S with simply forward/reverse and TB6612FNG with 0/1 on forward/reverse and a single PWM input for speed) and have seen the same issue.

Why is the PWM output so much more sensitive to noise/back-emf? And can I do something to avoid it? Or should I be using something other than PWM? (I've tried both the PWM driver and the low power PWM code).

A few notes: I've tried capacitors across the motor. The design requires a single shared power source (batteries). I'm regulating it to 3.3v.

UPDATE: I decided to do my own PWM type code without using the library and had the same problem. I then realized I've been using certain pins for PWM and when I could successfully reverse the motor before, I was using two different pins. After some testing [simply using nrf_gpio_pin_write] pins P0.11 and P0.14 are working for forward/reverse (and combinations using P0.12 and P0.13 are not). I am using a board I bought online, so there's a possibility that it's a factor.

UPDATE 2018-07-24: For testing, I'm just having it alternate forward/reverse every 2 seconds and it will sometimes reset. It might run for 10 seconds, it might run for more than a minute. I thought RTT might give me some insight but I don't see any error info--I do see debug messages I added. Any thoughts on why this is happening are appreciated.

Also, after the chip resets, I've read NRF_POWER->RESETREAS, and I get a value of 0.

[Einar Thorsrud]

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.

 

 

[stellar7]

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.

[stellar7]

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

[Einar Thorsrud]

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.

[stellar7]

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.

[Einar Thorsrud]

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.)

[stellar7]

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.

[Einar Thorsrud]

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:

1. Determine the maximum current consumption of the motor (typically when it starts).
2. 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.
3. 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.

[stellar7]

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.