dim led to minimize current consumption

RE: dim led to minimize current consumption

endnode — Tue, 23 May 2017 08:24:03 GMT

My golden rule so far is: if I don't understand how certain HW peripheral works, then I stick to SDK example (because Nordic guys know much better). I'm not sure if your code is not going too far from SDK without controlling the situation.

RE: dim led to minimize current consumption

endnode — Tue, 23 May 2017 08:22:41 GMT

Sorry, I'm not good in imagining just in my head how bunch of code works and I don't have time to test your code so I'm not sure what interrupts you really need to make your ode running continuously. In general all interrupt handling might get delayed if there is some higher priority execution blocking it, which might be the case when you use BLE stack (Soft Device) and it needs to do some radio-related processing. These things typically don't take more than 1-2ms, in extreme cases it can be 5~6ms or even more (if you use PDU extension + high throughput link and "stream" some data through the connection event). But I bet this is not really the problem for you right now so let's first make your code work in basic scenario (= FW boots and LED starts to dim and brighten with given period) and then you can test advanced use cases.

RE: dim led to minimize current consumption

endnode — Tue, 23 May 2017 08:18:01 GMT

Hi Sal, normally in embedded systems you initialize all HW (drivers) first during the boot and then you only run "safe" functions like start/stop. To the RTT tracing: have you ever made it work? If not then it looks like dangerous idea to debug it on custom code which is not known to be stable etc., rather make it work according to tutorials on something stable coming directly from SDK and then carefully port it to your project, step by step.

RE: dim led to minimize current consumption

Sal — Tue, 23 May 2017 03:13:42 GMT

Thanks for your help endnode, can you please provide more information about: "unless it blocks MCU for longer time then you can "program" in PWM registers". How can I check this? Please see the routine I am using above. I am using one instance of the pwm driver. And do not use handler that could block for a longer period. Would high duty cycle affect programming of registers?

RE: dim led to minimize current consumption

Sal — Tue, 23 May 2017 03:05:03 GMT

I learned my lesson the very hard way unfortunately.
The issue was due to reinitialization of the driver, that would return 8, then the error check would reset as it is other than success. I have updated my code, would you please let me know if there are better ways of avoiding initilization on every call to the driver. I call the routine few times. How abut the repeats and playback cycles, I am using the lowest possible clock to reduce duty cycle. Please advise here too.

Also please help with instructions to setup debugging on linux environment using segger RTT. I have added the app_error.h and app_error.c and added the DEBUG symbol on my makefile but I don't see debug traces when checking the error (after rebuilt it doesn't reset anymore but also no print of the error value, line number, and file name where the error was triggered). Thanks.

RE: dim led to minimize current consumption

RK — Thu, 18 May 2017 06:26:04 GMT

This is why you're supposed to develop first and then make the board later :)

There are no issues with PWM if you use Nordic's driver, so you must just have a bug.

RE: dim led to minimize current consumption

Sal — Thu, 18 May 2017 06:22:28 GMT

Hi RK, Thank you for your comment. Unfortunately I can't make design changes to the board at this time. I will check the datasheet to see if it is already implemented. Would you please let me know if there is a software solution or workarounds for the issues I am seeing with pwm?

RE: dim led to minimize current consumption

endnode — Thu, 18 May 2017 06:16:21 GMT

No, there is no real "simpler" solution then to alter GPIO high and low on the output line towards LED in time faster then your eye can notice so the effective duty cycle (time when line is HIGH divided by total time of one HIGH/LOW period) will determine how much "dim" it will look like. Now PWM is pretty straight forward solution as it should be able to run autonomously (thanks to things specific for nRF52 such as EasyDMA and PPI Tasks&Events) and thus no other activity should impact it (unless it blocks MCU for longer time then you can "program" in PWM registers). Quote from PWM driver documentation on Infocenter:

Key features include:

Multi-instance support
Two kinds of playback:
- Simple: a single sequence of duty cycle values
- Complex: two concatenated sequences
Sequences are played back a specified number of times
Optionally, the whole playback can be repeated in a loop
A user-defined event handler can be used to perform additional actions when a sequence or the whole playback is finished
If no event handler is used, playbacks can be carried out without involving the CPU

RE: dim led to minimize current consumption

RK — Thu, 18 May 2017 06:08:10 GMT

There's a simple solution if you are making your own board and want two brightnesses only and have two GPIOs you can use. Hook the LED up to two different GPIOs with two different resistors for two different brighnesses. If both are LOW, the LED is off, if one is HIGH and the other is set to high impedence, you'll get the LED powered via the one which is high. I guess if you power them both HIGH you'll get a third really bright brightness.

No PWM required.