Hello,
I would like to compile DSPS code for production boot from UART and with the extended sleep support.
I suppose extended sleep has to be enabled as follows:
/*Sleep modes*/
#define CFG_EXT_SLEEP
//#undef CFG_DEEP_SLEEP
//#undef CFG_EXT_SLEEP
Do I need to set DEVELOPMENT_DEBUG to 0?
#define DEVELOPMENT_DEBUG 0
Are there any other flags which have to be set for production code?
Regards,
Ilia
Device:
The code is intended for "device" side.
Hi imalamoud
你需要,因为你correctly said, define the CFG_EXT_SLEEP and the DEVELOPMENT_DEBUG to 0
also you must
define APP_BOOT_FROM_OTP if you are going to burn firmware on the OTP,
define READ_NVDS_STRUCT_FROM_OTP if the device is going to read NVDS data from the OTP
define CFG_WDOG
Thanks MT_dialog
Thank you!
Hello,
1. We are going to boot via UART without OTP. Do I still need to set DEVELOPMENT_DEBUG to 0 (in the code it mentions that 0 is for OTP boot)?
2. I re-compiled the code as per your recommended settings with Extended Sleep and tried to load to our test setup - break-away part of the BASIC kit (all jumpers removed) connected to FTDI UART via P0_2,_3 and flow control on P0_6, _7. I can not get it to advertise or in the best case it advertises for a very short period. Tried hardware and sw flow control.
However once I recompiled with extended sleep disabled it works fine - advertises and connects and streams data.
What could be the reason?
Hi imalamoud
1) Yes, you should set DEVELOPMENT_DEBUG to 0, unnecessary code will enter your program and also Watchdog is not going to reset your program if something happens.
2)Does your code executes when CFG_EXT_SLEEP is defined and downloaded using the jtag ? Have you made any changes to the code ?
Thanks MT_dialog
Hello,
We configured our device side as described above with CFG_EXT_SLEEP.
The code is uploaded via UART. HW flow control is set.
The device connects and sends data fine.
However the minimum power consumption is always about 600uA. Looks like it does not enter extended sleep.
What did we possibly miss?
Hi imalamoud
By defining CFG_UART_HW_FLOW_CTRL you set the device to operate under RTS/CTS (for the other post).
How do you measure the current consmption in your device? Can you see from smart snippets that your device does not enter extended sleep ?
Thanks MT_dialog
Thank you for your reply.
An small interface board based on a 14580 module has been developed and we measure directly in the board's circuit by a quality Fluke micro ammeter.
Such measurements are pretty common for us as our product (battery-powered LCR Meter tweezers) has sleep current below 2uA and the current
must be checked from time to time (the battery is small). So a measurement error is unlikely.
Data packets (10bytes) are sent once in a second. Between data packages RTS is pulled up. To send data, RTS is pulled down and we wait for CTS.
So what could be the reason for not entering the sleep mode?
Hi imalamoud,
the 600µA could well be caused by a connected debugger.
When I leave JTAG/SWD connected, I read about 0.6mA as well.
When in idle mode (powered up, but no code running), I measure about 0.6mA too.
In this case, it could be that the device doesn't enter sleep mode as you said.
Are other devices on the same supply that could cause thus high sleep current?
Best regards, BB_Dialog.
Hello,
JTAG/SWD is not connected. The board is separate has only UART pins, HW reset and power on the connector. The current is measured directly on the board so no other devices.
Again, perhaps we are doing incorrect DSPS CTS/RTS control.
We configured CFG_UART_HW_FLOW_CTRL and operate under RTS/CTS.
Data packets (10bytes) are sent once in a second. Between data packages RTS is pulled up. To send data, RTS is pulled down and we wait for CTS.
Is this correct?
What could be the reason for not entering the sleep mode? we tried several modules.
What could be the reason for not entering the sleep mode? we tried several modules.
Hi imalamoud,
The only think that we can come up with is that, maybe because the connection intervals of the DSPS are two small 12.5 ms (gives a small amount for sleep) there is a chance that the instrument doesn't show the actual power consumption. What you can try is to measure the power consumption in advertising mode (the intrervals are larger) or change (just for test, this will reduce the datarate) the connection interval parameter (#define APP_PARAM_UPDT_INTV_MIN 10 //N*1.25ms) and measure again. Also please try to measure the power using an analyser to make sure that the device isn't sleeping.
Thanks MT_dialog
Hello,
Let me re-cap:
- 14580 is mounted on a separate module board. The board is connected to MSP430. Only 5 pins of 14580 are used - PO assigned as RX/TX/CTS/RTS and Reset.
- We boot it with DSPS device side. Extended sleep is enabled.
- The consumption current can be measured at the battery with quality instrument.
- Without the 14580 board when MSP430 is in sleep mode consumes 1.2uA.
- Once the board is connected even when MSP430 sleeps consumption always stable at 600uA.
I repeat, MSP430 is in sleep mode.
Can you explain in detail - do we need pull up or pull down some pins (e.g. RTS) or set them in a third state? Which pins?
Can 14580 consume current via inputs?
Please help as we really hit this block and can not proceed.
Any comment on that?
I can send you schematic.
Hi imalamoud,
Just give us some time, we are checking on it.
Thanks MT_dialog
Hello,
Quite some time passed.
This issue still persists in our production device.
Do you have some ideas to try?
Hi imalamoud,
I dont think that the issue has to do with fact that the 580 is not sleeping but there should be somekind of leakage on the custom board through the pins, if you have a pin as a pullup and the connected pin is a pulldown then there is going to be a leakage. In the DSPS application both the RX and the CTS are pullup, so if the pins of the external MCU are pulled down when the device sleeps, there will be a leakage. Try to remove the pins one by one and check if the total current consumption of the system drops.
Thanks MT_dialog
Thank you for a fast reply
MCU pins are being turned to a third state (switched to inputs) to initiate sleep. Can it cause the leak. Also, can it be 0.5mA leak?
Just to verify, I have configured the following parameters
#define CFG_MEM_MAP_EXT_SLEEP
#undef CFG_MEM_MAP_DEEP_SLEEP
#undef CFG_DEVELOPMENT_DEBUG
sleep_state_t app_default_sleep_mode = ARCH_EXT_SLEEP_ON;
Did I miss something in configuration?
Hi imalamoud,
不,如果你有外部单片机我的针t think that there should be any kind of leakage. So i suppose that the fw runs when the 580 is attached and advertises (just to make things clear the device sleeps between the advertising events ), is there any chance that there are pending data in the DSPS queue ? If for example while the device advertises its receives data, this will keep the device awake (even one character will keep the device in no sleep mode while it advertises). So perhaps the 580 receives junk from the device at some point, there is no connection, therefore nowhere to send the data so it stays awake until a connection is made. You can also detach the 580 from the MCU and measure the power consumption in stand alone in order to isolate the problem (check if its something related with the external MCU or only with the 580).
Thanks MT_dialog
We noticed that when CTS-RTS are disconnected from the MCU there is still some activity on those 580 pins every 3.5mSec.
Does it tell you something? Could we inadvertently enabled (or left enabled) some timer?
Hi imalamoud,
I dont think so, the DSPS doens't use any timer in order to drive the RTS, every time that the device wakes up and advertises it pulls down its RTS in order to indicate that a reception can be performed because it has awaken, the application when advertising it keeps the RTS low for about 5 ms and sleeps (hence the RTS is high for about 100ms which is the advertising interval). When the device is connected, the RTS is low for about 2.5 ms and high for about 10ms.
Thanks MT_dialog