Hello support,
我正在考虑使用外部中断input of DA 14585 to asynchronously return (from exteded sleep) using external MPU.
I am referring to the document (Training_04_Sleep mode configurations and power measurement_0.pdf). (Page 9)
SDK :6.0.8.509.
The external MPU and DA 14585 are connected using SPI I/F.
I have two questions.
Q1. During exteded sleep
Behavior is different between Keil-uVision debugging operation and actual operation.
First I set to "exteded sleep" when DA 14585 is not communicating, and set action from restore DA 14585 from Sleep state by using port interrupt.
I would like to communicate with SPI immediately after returning. ,
In uVision and J-LINK debugging environment, it works without problems.
Next, if I write this program to the external SPI flash and let it operate standalone, it will stop working. (It will not return.)
Looking at the current value, it looks like DA14585 has recovered. However, SPI communication with external microcomputer seems not to be done.
Are there any differences in the operation between the debugging environment (Keil - uVision and J - LINK) and the real environment (using flash)?
(For example, in the debugging environment, the power supply of the RAM is not actually turned off.)
(2) Bluetooth communication in progress
If I do a return operation using port interrupts in the same way during Bluetooth communication,
The function lld_sleep_compensate_func (in rwble.c) is called,
Then it stops with ASSERT_WARNING (0) on the last line.
This phenomenon occurs in both the debugging environment (uVision and J-LINK) and the real environment (using flash).
Is it that the period of sleep has been too short? Or do you have something to think about?
Could you please advise me for workaround.
In addition to the above information, if necessary items, please request to us.
regards,
Jun-ichi
Hi Jun-ichi Tobe,
如果我能明白你想accomplish in your project is to wake the DA14585 up using an external MPU interrupt? Could you please clarify what you are trying to? Also, could you please make clear what do you mean with “return” that you mentioned in your first question? Do you mean wake the device up? Did I understand correctly? And your problem is that you are not able to wake up the DA14585? If you follow the DEVELOPMENT_DEBUG definition you will be able to see that there are not any differences between he debugging environment (Keil - uVision and J - LINK) and the real environment and the RAM is powered off. Regarding your second question, be aware that if this assertion hits then the LP ISR lasts longer than the time that has been reserved via LP_ISR_TIME_XTAL32_CYCLES and LP_ISR_TIME_USEC. Could you please let me know if you have any transactions of the SPI into the periph_init() function and they takes too long?
Thanks, PM_Dialog
Thank you for your comment.
About Q1
What I want to accomplish is to asynchronously wake sleeping[Extended sleep] DA 14585 using external MCU and external interrupt.
(a) In Keil's debug mode, DA14585 could wake up from sleep.
(b) On the other hand, if FW is written to the external SPI flash memory of DA 14585, it has failed to wake up DA 14585 from the sleep state.
What are the differences in operation between (a) and (b)?
How can I make it work correctly in environment (b)?
Or, how can I verify whether RAM is on or off in the environments (a) and (b)?
Regards,
Jun-ichi
Hi Jun-ichi,
Well, if the 585 is able to boot properly from flash then it shouldn't have any difference between running the code from the flash or when debugging regarding the wake up procedure. If the device doesn't wake up when you are booting from flash perhaps you should check if the device is actually booting (do you advertise when the device boots up ? do you have
any indication that the device has booted ?). I suppose also that you are using sleep, so what kind of sleep you are using ? Have you tried to boot from flash with no sleep used ? Is it
operational that way ? Also when booted from flash (while sleep) you should be able to attach on the device in order to check if the device is stuck on an assertion or a hardfault.
What you can also try is to burn the ble_app_sleepmode in flash (it has a similar functionallity to what i suppose that you do, it goes to sleep and wakes up from an external interrupt). So try to wake the example of the SDK while burned in flash and check if its working on your side.
Thanks MT_Dialog
Hi!
>>I suppose also that you are using sleep, so what kind of sleep you are using ?
-->I have used "Extended Sleep" mode.
If Extended Sleep is used, are there any differences in RAM status depending on the debugging environment?
regards,
Jun-ichi
Hi!
About Question 2:
During the process of wake up from sleep, SPI communication was included
and as you indicated, I found that it took too long !
It was solved by correcting the corresponding part.
Thank you!
Jun-ichi
Hello !
I report the test environment about Q1( During exteded sleep)
Base sample project: ble_app_peripheral
SPI processing: Implemented in "spi_hcl.c"
I will describe the procedure.
[Host MPU (SPI Master) → DA 14585 (Slave)]
1) Wake up DA 14585 using port interrupt.
2) Call the function arch_set_sleep_mode (ARCH_SLEEP_OFF) to wake up.
3) After DA 14585 communication, set the port interrupt and call the function arch_set_sleep_mode (ARCH_EXT_SLEEP_OTP_COPY_ON)
and set it to Extended Sleep.
[SPI transmission from DA14585 (slave) to host MPU (SPI master)]
When DA14585 performs Bluetooth communication, it outputs a DREADY signal and performs SPI communication.
At that time, DA14585 does not change the sleep setting.
Result (current measurement)
[When project is written to SPI flash and executed]
When calling arch_set_sleep_mode (ARCH_SLEEP_OFF); in the port interrupt,
the current consumption increases from about 400 uA to 600 uA in a few seconds and the DA 14585 will NOT accept SPI communication from the host MPU.
When sending the advertise start command while consuming current is 400 uA, advertisement is started.
If I call wdg_freeze () after calling ARCH_SLEEP_OFF, it seems that current will not increase for the moment.
Because it becomes abnormal in a couple of seconds, I thought that the watchdog timer was working.
The wdg_freeze function seems to be effective,I think.
This is only when I wrote the FW to SPI Flash.
[Run with Keil's debugger]
After port interrupt, SPI command is accepted.
After that DA14585 can also execute Bluetooth communication.
Where are the differences depending on the execution environment? Memory setting? Build setting?
regards,
Jun-ichi
Hi Jun-ichi Tobe,
Could you please try to describe more clearly what you are trying to accomplish and which is your issue? Sorry, but I am not able to understand which is your problem. Regarding the Q1, as you have already mentioned in your previous post, you figured your issue out. Is that correct? Now what you are trying to do? You boot from the SPI flash and you are using the external MCU in order to send commands into the DA14585? Regarding the current consumption, the problem is when booing from SPI flash? Have I understood correctly?
Thanks, PM_Dialog