Virtual com port for log

[Johan.h]

When I debug with DK dev board, data is sent to the virtual j-link com port and displayed on my PC.

When I use target device (using J20 of nRF52 DK) the virtual com port is not sending any data.

What can be the reason for that? (Note: SWO pin is not connected, is this the problem?)

One more small problem. As soon as the program hits idle_state_handle(), the debugger gets an exception, and system needs a reset. How to overcome this?

Thanks.

[Jared]

Hi,

When I debug with DK dev board, data is sent to the virtual j-link com port and displayed on my PC.

When I use target device (using J20 of nRF52 DK) the virtual com port is not sending any data.

What can be the reason for that? (Note: SWO pin is not connected, is this the problem?)

When you're debugging the IC on the nRF52 DK, the nRF will send log data (if UART backend is enabled) to the TX and RX pins that are connected to the interface chip on the board. The interface chip on the board will automatically send all data that it receives over the UART pin to the virtual com port by using the USB interface, thus interface chip will act as a bridge between the onboard nRF52 and the computer by sending all data received on the UART pins to the USB interface. When you use the P20 header, the UART pins are not connected to your custom board. Only the SWD pins which doesn't send debug data over UART. You can either connect the UART pins on the DK to the UART pins on your custom board, or change the log backend to RTT instead of UART. RTT use the SWD interface to output logs. 

One more small problem. As soon as the program hits idle_state_handle(), the debugger gets an exception, and system needs a reset. How to overcome this?

Is this a BLE application?

regards

Jared 

[Johan.h]

Understood, thanks.

Yes, it's a BLE application. It has a few timers to measure sensors, battery level etc. It draws too much current (about 5 ma) and I am searching for the reasons(s). I need it to advertise once per 5 sec, and when connected to use as low power as possible, with connection intervals of 250 - 500 ms.

[Jared]

Hi,

I see. Just to ensure that the HW and your measurement setup is ok. Can you flash your custom board with the Ble_power_profiler application and report what current you measure? 

Jared said:

One more small problem. As soon as the program hits idle_state_handle(), the debugger gets an exception, and system needs a reset. How to overcome this?

Also, can you tell if the system reset if it's not run in debug mode? What exception is thrown, can you share a screenshot of the debugger when it's hit the exception? Please include any error log that is printed etc. 

regards

Jared 

[Johan.h]

I am using PKK2, with  ble_power_profiler, when system stop (before clicking the button) the current is 0.3uA.

The system is a battery powered sensor for water level, and a central unit connected to pwor supply, which start a pump when water level is low. detecting low water level is not time critical and can be done every very long time like 30 seconds. once the pump starts, it is critical to  stop it on time to prevent overflow. I wonder what might be the best policy in term of low power at the sensor. My current way is to only advertise the state. When the adv data is water low, then the central unit connects to the sensor, starts the pump, and checks the water level while connected. So is there a better way to conserve battery, should I not connect and just advertise the state more often?

Thanks

[Jared]

Hi,

Johan.h said:

I am using PKK2, with  ble_power_profiler, when system stop (before clicking the button) the current is 0.3uA.

Ok, this is about what I would expect when measuring the current consumption of that example, which probably means that your HW and measurement setup is ok.

Johan.h said:

The system is a battery powered sensor for water level, and a central unit connected to pwor supply, which start a pump when water level is low. detecting low water level is not time critical and can be done every very long time like 30 seconds. once the pump starts, it is critical to  stop it on time to prevent overflow. I wonder what might be the best policy in term of low power at the sensor. My current way is to only advertise the state. When the adv data is water low, then the central unit connects to the sensor, starts the pump, and checks the water level while connected. So is there a better way to conserve battery, should I not connect and just advertise the state more often?

Could you fill in your advertising and connection parameters into the online power profiler and see what it estimates?

Can you also share a plot from the PPK2 when measuring your application that shows the 5 mA current?
Are you using any other peripherals that could keep the CPU from going into IDLE sleep in the main loop between connection events?

One more small problem. As soon as the program hits idle_state_handle(), the debugger gets an exception, and system needs a reset. How to overcome this?

Does this also happen when you don't run the program in debug mode? What exception is thrown? Does the log output the error?

regards

Jared 

[Jared]

I forgot to add the link to the online power profiler, here it is.