Hi Dialog,
We have an existing design based on the DA14583 that uses DSPS as detailed in UM-B-038, UART comms in/out is h/w flow controlled at 115200 baud. Communication is always from DA14583 to a custom android application with the application always initiating connection to the advertising DA14583.
We are now switching to the Inventek DA14585 based module and latest DSPS as detailed in UM-B-088. Initial tests have not been very successful. We have comms in 1 direction (Android application to DA14585 and out of the UART TX) but data into the DA14585 does not seem to be transmitted and the h/w flow control stops.
We have not modified our custom application and want your comments on the following please.
1. Do you expect an existing android application based on UM-B-038 to work seamlessly with the latest DSPS and DA14585 (GPIO allocation adjusted to suit h/w of course)
2. Has w/h flow control sense changed between versions ?
3. Are there any default compile switches that should be disabled to allow compatibility with existing android applications ?
4. Is there any version migration document I have missed?
Any help would be greatly appreciated, the number of compile switches and configurations is significant and we are under time pressure to get this working, something we thought would be a simple compile with GPIO adaptations.
非常感谢
Garry Jackson
Hi Delta-GRJ,
Thanks for your question online. Please find my comments below :
Can you please indicate are you able to connect with your custom mobile application? Th only issue is that the DA14585 is not able to transmit the UART incoming data over BLE? If yes, I assume that this is due to UART misconfiguration. Are you using any of our Pro-DKs?
Thanks, PM_Dialog
Hi PM_Dialog,
Thanks for the reply, here is further detail that I hope will assist:
1. I am using Keil project for DA14585 DSPS Device with extended sleep and remote config enabled.
2. I am using a new custom development PCB using the Invertek module (585 based) which has the UART taken to pads for hooking up to an external existing board I designed a while ago. The external board has a STM32 connected to a DA14583 which was running DSPS (UM-B-038 based). I removed the DA14583 linking TX,RX,CTS,RTS to the new board with the invertek module. The DA14585 UART signals, as defined in user_periph_setup.h are:
#define GPIO_UART1_TX_PORT GPIO_PORT_0 // (DA to STM)
#define GPIO_UART1_TX_PIN GPIO_PIN_2
#define GPIO_UART1_RX_PORT GPIO_PORT_0
#define GPIO_UART1_RX_PIN GPIO_PIN_3
#define GPIO_UART1_RTS_PORT GPIO_PORT_0
#define GPIO_UART1_RTS_PIN GPIO_PIN_1
#define GPIO_UART1_CTS_PORT GPIO_PORT_0
#define GPIO_UART1_CTS_PIN GPIO_PIN_5
This GPIO config is confirmed by the Dialog SmartConfig application (which I can connect to) and I also used the DA SmartTerminal hooking TX/RX together and confirm the data is looping when individual cahracters are typed.
3. I can establish BLE connections to the DA14585 OK.- from my custom application and from the Dialog tools.
4. I can send over BLE from my custom android app to the DA14585 and see the 30 byte packets appear on the UART which are correctly interpreted by the STM32.
5. 1s after the 30 bytes from the custom App has arrived at the STM32, the STM32 will begin to send datablocks of typically 2K bytes in size with a 100mS delay between, always waiting for the DA to lower RTS and always pausing when its raised on each byte sent.
6.我钓了一个逻辑分析仪和可以看到the DA push out the 30 byte RX payload and then 1s later the STM32 start to push out its data. The DA maintains RTS low for about 21ms, raises it for 55uS then lowers it for a further 21ms (during which time data is being send from the STM32). After this the DA raises RTS and it remains in that state for the remainder of the connection. This typically represents about 420-480 characters at 115200 baud. Note the 55uS raising of RTS seems to be mid byte from the STM32 so this is not looking correct.
7. A few minor changes to support the Invertek DA implementation, these I do not think are related to this issue.
I agree it feels like a UART handshaking problem but the interaction on the logic analyser seems to be as expected (apart from the DA preventing any data being pushed after 40mS or so). I did not know if this current version of the DSPS was compatible with historical android apps.
I will review the docs you signposted but any obvious issues please advise. This is, as always, time critical for me.
Many thanks
Garry J
Hi PM_Dialog
Further information I hope you can review with my previous post and offer additional suggestions for us:
The core question we had, we have now investigated and answered and confirm that the latest DSPS 6.150.4.50 will work with historical Android apps, specifically thouse developed using DSPS 5.150.2 (SDK for DA14583) - however I continue to have a problem with one specific custom application that only works with DSPS 5.150.2. This application connects as expected but always presents handshaking as I previously described, ie. RTS from DA is set to low for 21mS and data starts from the UART into the DA but after 200-250 bytes it raises for 55uS then lowers again for a further 21mS before returning hi for the remainder of the connection blocking all data to send over BLE.
I have tried delaying the inbound data after the connection is established without effect.
Can you please advise if there is a connection startup difference between the versions and any way I can debug this. I do not have the Android source or access to the origional Android developer.
Is this the only way to get technical support from Dialog ?
Many thanks
Garry Jackson
Hi PM_Dialog
Further information I hope you can review with my previous post and offer additional suggestions for us:
The core question we had, we have now investigated and answered and confirm that the latest DSPS 6.150.4.50 will work with historical Android apps, specifically thouse developed using DSPS 5.150.2 (SDK for DA14583) - however I continue to have a problem with one specific custom application that only works with DSPS 5.150.2. This application connects as expected but always presents handshaking as I previously described, ie. RTS from DA is set to low for 21mS and data starts from the UART into the DA but after 200-250 bytes it raises for 55uS then lowers again for a further 21mS before returning hi for the remainder of the connection blocking all data to send over BLE.
I have tried delaying the inbound data after the connection is established without effect.
Can you please advise if there is a connection startup difference between the versions and any way I can debug this. I do not have the Android source or access to the origional Android developer.
Is this the only way to get technical support from Dialog ?
Many thanks
Garry Jackson
Hi Garry Jackson,
Thanks for your comment. Let me check this internally and I’ll get back to you ASAP.
Thanks, PM_Dialog
Hi PM_Dialog
Its been 11 days do you have any comments internally that may help with this issue ?
I have investigated further and additionally confirm that the latest DSPS 6.150.4.50 works with 2 of my 3 existing custom android applications, just so happened the first round of my testing was with the app that does not work.
第三个应用程序是很重要的,perfe工作ctly well with the original DSPS on the '583. From looking at the limited debug available via android studio (remembering we do not have the source) I can not see an obvious difference between this app working with my old hardware and not working with the new hardware. It looks as though the connection parameters are the same and registered notification of RX is setup correctly but nothing is ever sent to it. All I can think is a difference in startup/setup that on connection is preventing UART RX and BLE TX ?
Please advise, we need confidence to switch to the '585 for production as soon as possible.
Thanks
Garry J
Hi Delta-GRJ,
My apologies for the delay. Does the 3rdcustom application developed by you? Is this application available for free download?
Since it is working with 2 of my 3 existing custom android applications, I assume that the specific issue is related with the mobile application.
Would it be possible to use a BLE Sniffer tool, and share a sniffer capture, so that we can understand what is happening over the air?
Could you please test this also with the Dialog DSPS mobile application? It is available both for Android and iOS. You can also find the source code In the DSPS portal:
//www.xmece.com/products/dialog-serial-port-service-dsps
Thanks, PM_Dialog
Hi PM_Dialog
The custom application is not public and all applications relate to our hardware use case, which is sending 2K datablocks over the connection from DA14585 to the Android applications. This is in response to the application sending commands to our board (BLE->DA14585->STM32) to initiate the transfer. In each the failure I can indeed see the command arrive and the STM32 begin to send data to the DA14585 but this data never seems to get pushed over BLE.
I will investigate if I can capture using a BLE packet sniffer. looks like there is no simple answer and while the issue probably is with this failing android application, its a change to the DSPS project/platform that is highlighting this mobile application deficiency. I hoped it would be a known issue and sequence/timing related.
Thanks
Garry J