I'm trying to implement a "heartbeat" feature for DSPS 5.150.2 on DA14580.
The idea is to have a special message which my host application would send to DSPS via the UART and get
a response from DSPS (also via the UART) without transmitting the data over BLE.
1.What would be the right approach to implement such a feature?
2. Which code / functions should I customize in order to implement "heartbeat"?
Any help would be greatly appreciated.
Device:
Hi shpasser,
Could you please clarify what you mean with the "heartbeat" feature and what you are trying to accomplish? Do you mean the Heart Rate profile to be added into the DSPS reference application code?
Thanks, PM_Dialog
Hello,
The "heartbeat" feature is a mechanism (actually a simple message exchange) used in order to make sure the node,
which in my case is the firmware running on DA14580, is "alive". In case it is not "alive" the host software shall issue
DA14580's reset and reprogram it via the UART (the same UART used later by DSPS device).
Most of the time DSPS works fine, but sometimes it crashes and then I would need to know that the crash occurred
and reset and reprogram the DA14580 chip.
Thanks in advance.
Hi shpasser,
Thanks for your information. Could you please run the DSPS firmware in debug mode with the debugger hot-attached? Does the code crash somewhere? Please try to clarify what happened. Probably, you get an NMI or a hardfault. Also, you mentioned that sometimes the firmware crashes. Could you please clarify it?
Thanks, PM_Dialog
Hello Dear Support,
The DSPS crashes I experienced are very rare and I was not able to reproduce them while running with the debugger attached.
The system I'm working on shall be connectable at all times and that is the reason why I need to implement the "heartbeat" feature.
Since I have to program the DA14580 via the UART a simple "reboot-on-fault" would not do the job.
Thanks in advance.
Hi shpasser,
Since that you have modified the DSPS project, I am not aware what you have added into the application code. Be aware that the DSPS is a reference design for very specific applications. You mentioned that “The system I'm working on shall be connectable at all times ” , could you please clarify it? Do you mean that you would like to advertise and be connectable when the device is connected with one other peer DSPS device? Could you please provide me more inputs about what you have done?
Thanks, PM_Dialog
Hello again,
I'm not using a modified version of DSPS yet. So, the crashes are actually connected to the DSPS code itself.
"Connectable at all times" for me is even if the DSPS app crashes my host application should be able to know
that the crash happened in order to reset the DA14580 and reprogram it via the UART.
So now we are back to my original question, what would be the right way to change the DSPS code in order
to implement "Connectable at all times"?
Thanks in advance.
Hi shpasser,
You have to debug the code and find where the DSPS gets crashed. If you run it with the debugger attached and if the problem if from the host’s side, the firmware should stack somewhere. For example might stuck into an assertion or into the NMI handler or into the hardfault handler. Which call back functions are triggered before the code gets crashed? You could add some break points and debug it step by step. The best practice to debug your code is to have optimization Level-0 (-O0). So, navigate into “C/C++” tab of “Options for Target” from the Keil environment and the optimization into Level-0 (-O0).
Thanks, PM_Dialog
Hello Dear Support,
Thanks for the thorough explanation. I already tried to debug DSPS several times and as I described before,
the crashes are very rare (but still they exist) and I was not able to pinpoint the issue using the debugger.
It can take a day till the issue appears and while I have several systems working the approach of debugging is the best,
but not practical in my situation.
So, I’ve decided to try and change the DSPS code in order to be able to communicate with DSPS in Out Of Band manner in order to be
able to reset and reprogram the chip via the UART when it becomes unresponsive.
你能协助我的信息吗best/right way of implementing of such a feature on top of DSPS code.
Thanks in advance.
Hi shpasser,
Could you please describe the procedure you are following? I’m sorry, but I am little bit confused with your description and you issue is very generic. Let me ask you some questions in order clear the things out.
Since your issue is quite generic and rare, it would be very helpful to provide me some inputs in order to understand what getting wrong.
Thanks, PM_Dialog
Hello Dear Support,
Thanks for your reply.
1.我使用“sps_device”只有在色差上运行ta module.
2. The "host" application is running on STM32L4 and programs Murata (with DSPS device code) via UART and communicates with it via the same UART.
3. There is a "client" application which runs on iPad which communicates with my "host" application running on STM32L4 via Murata module (DSPS device).
4. The "sps_device" is configured to work without HW (not supported) or SW (not applicable) flow control.
5. Sometimes, very rare (maybe once a day) the "sps_device" running on Murata module becomes unconnectable probably due to one of the reasons you described (assertion or some kind of crash).
6. When (5) happens I can connect to my "host" application running on STM32L4 via additional UART (not connected to Murata module) and see that it is still functioning, but the messages sent via BLE stopped arriving (in both directions).
7. I was not able to reproduce the issue while connected with a debugger to Murata module.
8. In order to prepare a workaround solution I've decided to implement "out-of-band" communication ("heartbeat") between my "host" application running on STM32L4 and "sps_device" running on Murata module, so I could reprogram Murata module when it becomes unresponsive.
9. The only communication my "host" application has with Murata is via the UART (which is also used to program "sps_device").
10. Please advice on possible code customizations or source files to be changes in order to implement the described workaround.
Thanks in advance.
Hello Dear Support,
Do you have any suggestions form me?
Thanks in advance.
Hi shpasser,
First of all, if you are not using flow control and the device goes int extended sleep mode, it will no be able to wake up. So, if you would like to don’t have flow control, you will have to remove the extended sleep mode and the chip will be operating only in active mode. Regarding the workaround that you will have described, we have never used it and thanks for let us know. If I am able to understand correctly, the host has to send some messages over UART to the Murata module? Which application does the host run? I suppose that the DSPS mobile application I connected with the Murata module and not with the STM32L4.
Thanks, PM_DIalog
Hello Dear Support,
1.In order to avoid sleeping I replaced
const static sleep_state_t app_default_sleep_mode = ARCH_SLEEP_ON;
with
const static sleep_state_t app_default_sleep_mode = ARCH_SLEEP_OFF;
inuser_config.h, is this correct?
2. The communication path is as follows: STM32L4(Host) -> UART -> Murata(DSPS) -> BLE -> iPad(BLE App)
3. Waiting for your recomendations regarding the possible code customizations or source files to be changes in order to implement the workaround.
Thanks in advance.