⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
8 posts / 0 new
Last post
florent
Offline
Last seen:3 years 6 months ago
Joined:2017-08-08 11:42
DA 14580 Debug Mode to Autonomous

Hi dialog,

I am currently working on a project which use a DA 14580. The goal of my system simple : i send data ( packet of 20 octets ) through an SPI link to the DA14580. Then i use the beacon mode to send this data ( placing the data from the SPI reads in the advertising string ) and i am able to receive all that data with my mobile phone's bluetooth scanner. I work on IAR for the global code ( collect data from sensor and send them to SPI flash link ), and I load a binary file for the Bluetooth configuration at the beginning of my code, through the SPI . The binary file is created when i build my Bluetooth program on U vision ( I use basic program provide by Dialog Semiconductor for the beacon mode ).

My problem is that the system works correctly in debug mode. So when I launch the system with IAR, the BLE module boot correctly and send the data correctly. But when I try to do it without the debug mode, it doesn't work. I reset the system, so the code starts running from the beginning, but the BLE module doesn't send any data.

The system works like this :
微控制器醒来,并初始化BLE module. When the micro controller is ready to send a data, it send a wake up signal to the BLE module, which start his configuration. Then the micro controller send the data to the BLE module through the SPI flash. Then the BLE module send the data by beacon mode, and go to sleep when it is finish.

So what I would like to know is what is the difference between the debug mode and the autonomous mode ?
Any idea to solve this let me know.

Best regards,
Florent

Keywords:
Device:
MHv_Dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2013-12-06 15:10
Hi Florent,

Hi Florent,

This appears to be a sleep mode issue. As an experiment, to either confirm or rule this out, please disable sleep in your DA14580 firmware and let me know whether this works.

Also please let me know the following:

  1. What type of sleep mode are you using (Deep sleep or extended sleep)?
  2. When you say "debug mode"... Do you mean with the J-Link attached?
  3. Your wake-up mechanism - is it using the wake-up timer? (a "normal" gpio interrupt will not work during sleep)
  4. You use the phrase "SPI flash" in your description. Can I assume that you meant to say SPI interface and that there is no flash involved?

/MHv

florent
Offline
Last seen:3 years 6 months ago
Joined:2017-08-08 11:42
Hi Dialog,

Hi Dialog,

After some test, I saw that the issue is a bit different. Indeed, I just send only one data ( to be sure I put a LED each time that I send one + I receive only the first data through the BLE scanner), and then the BLE module seems to be stuck.

1. I use extended sleep.
2. Yes, debug mode is when I run the code with the J-Link module with IAR.
3. My wake up mechanism is an external wake up, the micro controller that I use send a signal (SYS_WAKEUP) when I want to send a packet, and there is an interruption on the BLE module when it receive the signal from the micro controller. But with this device, it works perfectly in "debug", and it seems to work at least one time without the "debug" mode.
4. Yes I wanted to say the SPI interface sorry.

Regards,
Florent

MHv_Dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2013-12-06 15:10
Hi Florent,

Hi Florent,

When you are using the debugger, you are really never going to sleep (real sleep mode turns off the controller in the DA14580, so it would not be possible to debug when sleep is enabled). When you run the code autonomously, as you say, the device will remain awake for 2 seconds after code starts executing which is why you will see one or two advertisements before the device goes to sleep.

Two things are required for your implementation to work with extended sleep mode:

  1. You must have a sleep clock defined to match your hardware. If you have an external 32k768Hz crystal, then this should work right away. If you do not have an external crystal, you must define CFG_LP_CLK to LP_CLK_RCX20 in the file da1458x_config_advanced.h (line 28)
  2. During sleep, a normal GPIO interrupt will not trigger a wake-up. You will have to use the wake-up timer (see the UM-B-051 section 10.7 for details)

Let me know if any of this helps.

/MHv

florent
Offline
Last seen:3 years 6 months ago
Joined:2017-08-08 11:42
Hi Dialog,

Hi Dialog,

So if I understand well, it is not possible to go to sleep mode in debug. It seems weird, cause when I am in debug, I run the code on the u-processor which have a binary file in input linker ( On IAR ). So I don't really run/debug the BLE module, I just load this binary file, which is used only one time, at the beginning of my program to initialize the BLE module through the SPI.

So if sleep mode doesn't work in debug, how it is possible that I manage to receive the values on my smartphone BLE scanner when I shake my board ( I have an accelerometer which send a signal though GPIO when it detect a vibration, and then I send some data, and this GPIO signal wake up the BLE module with an interuption) in debug mode ?

Moreover, you tell me to use the the wake-up timer, so it means that I can really control when I send data with my u-processor, cause the shake will not be efficient, cause of the gpio signal ?

Thanks for your help,
Best regards,
Florent

MHv_Dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2013-12-06 15:10
Hi Florent,

Hi Florent,

Let's step back a bit :-)

Please explain in detail what you mean by debug mode. Are you, or are you not, using the serial-wire debugger on the DA14580 (J-Link), and, if so, is the debugger attached?

You can use the debugger in sleep mode, but the device will not actually go to sleep (as this would de-attach the debugger as the controller is powered off).

In order to use sleep mode without the debugger attached, you will need to configure your sleep clock to match your hardware as described above. Otherwise the device will not wake up from sleep.

The wake-up timer is actually a hardware block on the device that allows you to wake the controller up from sleep mode when a input GPIO changes state. Please see the reference manual for details (UM-B-051). This will allow you to wake up the DA14580 as soon as your accelerometer toggles its interrupt output pin/pins.

/MHv

florent
Offline
Last seen:3 years 6 months ago
Joined:2017-08-08 11:42
Hi Dialog,

Hi Dialog,

By debug mode I mean : I use a SWD on my micro-processor (ADUCM3029), and this microprocessor just send some data to the BLE module through the SPI link. This microprocessor also have as input a binary file which is the configuration of the BLE module, and send this configuration at the very beginning of the code. So no, the DA14580 is not attached to the J-link module, I just used the SWD on the microprocessor to send step by step the packet to the BLE module.

So each time that I want to test one of my BLE code, I compile on u-vision the BLE code, it create a binary file, then I linked this one through AIR with the code for the ADUCM3029, and then I debug the ADUCM3029 with SWD.

So the problem is that when I don't connect the J-link module to the rest of microprocessor, the DA14580 only send one data, and go to sleep one time ( I debug it with a LED).

So the external wake up is working, but only once.
Thanks,
Florent

MHv_Dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2013-12-06 15:10
Hi Florent,

Hi Florent,

Thanks for the detailed explanation.

Here is a list of things to look into:

  1. Your wake-up scheme must utilize the wake-up timer hardware block in order to wake the device up from sleep. A standard GPIO interrupt will not work unless it happens while the DA14580 is awake (it remains awake for 2 seconds after boot-up and will wake up for any Bluetooth event which likely explains why it works once). Please see UM-B-051 section 10.7 for details.
  2. Waking up from sleep takes some time and you should implement some sort of handshaking or a fixed delay in order to make sure that the SPI interface on the DA14580 is fully initialized before you start sending data.
  3. I cannot explain why your observations are different when the host processor is attached to a debugger, but this could indicate timing issues and potentially realetd to bullet 2 above

/MHv