Hello all,
I'm currently exploring the SPS sdk 6.150.6.77 version with the development kit pro. Just to gain confidence with the sdk, I have been trying to send and receive data without any significant modification.
The only change I made was to set the BLE_REMOTE_CONFIG to 0, otherwise I get this error ".\out_531\dsps_device_531.axf: Error: L6388E: ScatterAssert expression (ImageBase(RET_HEAP_MSG) + ImageLength(RET_HEAP_MSG) < (((0x7fc9c00) + (((((0x33e) + (((0x3 * 0x3) + (0x3 + 0x3))) * (0x106))) + (((0x8) * (0x106))) + (0x6)) - ((((0x33e) + (((0x8) + (((0x1))) + (0x3)) * ((((0xfb)) OR 0x1) + 0x4 + 0x7))) + ((0x8) * ((((0xfb)) OR 0x1) + 0x4 + 0x7))) + (0x6)))) AND (0xffffc00))) failed on line 153 : (0x7fc9c04 < 0x7fc9c00)", probably because the image is too heavy with \ this part of the code.
After setting BLE_REMOTE_CONFIG to 0, the code compiles without error. The problem is that when I try to send text from the terminal to the application everything works fine, but when I try to do the opposite I don't receive any message to the terminal. Debugging the code I notice that when watching the contents of the variable "req" in the void sps_server_data_receive(struct spss_env_tag *spss_env, void *msg) method, the "req->data" field (I guess is the message) is empty. I don't know if I am doing something wrong or if there is a problem with the sdk or the application.
As I said, I'm currently using the development kit-pro, the Smart Console application and TeraTerm with 921600 baud rate and RTS/CTS flow control.
I have another question, if possible. I read 3. Architecture (renesas.com) to better understand how the architecture is designed. What is not quite clear to me is how the transfer of a message longer than the maximum length of the feature is actually implemented. My guess is that when I want to send a file from the smart console to the terminal, the application first divides the file into packets of the length of the feature, then sends each packet by continuously rewriting the characteristic value while the DA14531 continuously reads it. These packets are collected in a buffer implemented as a linked list and then sent by DMA uart to the terminal. Am I right?
Thanks in advance for the answer
Hi Giorgio,Thank you for posting your question online.
Giorgio said:The only change I made was to set the BLE_REMOTE_CONFIG to 0, otherwise I get this error
Instead of modifying the BLE_REMOTE_CONFIG definition you should undefine the CFG_PRF_REMOTE_CONFIG macro in user_profiles_config.h file. It will have the same affect and you will not have to modify the SDK files.
Giorgio said:After setting BLE_REMOTE_CONFIG to 0, the code compiles without error. The problem is that when I try to send text from the terminal to the application everything works fine, but when I try to do the opposite I don't receive any message to the terminal. Debugging the code I notice that when watching the contents of the variable "req" in the void sps_server_data_receive(struct spss_env_tag *spss_env, void *msg) method, the "req->data" field (I guess is the message) is empty. I don't know if I am doing something wrong or if there is a problem with the sdk or the application.
It is not exactly clear to me what you have modified on the SPS SDK. Could you please share a code snippet of the changes you have made in order to send/receive data?
Giorgio said:I have another question, if possible. I read 3. Architecture (renesas.com) to better understand how the architecture is designed. What is not quite clear to me is how the transfer of a message longer than the maximum length of the feature is actually implemented. My guess is that when I want to send a file from the smart console to the terminal, the application first divides the file into packets of the length of the feature, then sends each packet by continuously rewriting the characteristic value while the DA14531 continuously reads it. These packets are collected in a buffer implemented as a linked list and then sent by DMA uart to the terminal. Am I right?
When we sent a file via SmartConsole you can go on the Data/File Streaming tab:There you can select a file, and the chunk size that this file will be sent to the DA14531:The application will then divide the file you had selected into Chunks sizes that you set. It is not mandatory to use the exact length of the characteristics. Even if you use a higher chunk size, i.e. 500 or 600 bytes of data per chunk, then the L2CAP Protocol will start working. It is the BLE stack that will handle this and you will not have to do anything. Since BLE Specification allows only 251 bytes of data to be transmitted per packet, the L2CAP protocol recognizes when we have more data and it breaks those data into different packets.Please refer on the screenshot from a BLE Sniffer capture between DA14586 with SPS SDK and SmartConsole application when I sent over 251 bytes in one characteristic:Keeping the Chunk size in a small value can guarantee no data loss. The more you increase the value of the chunk size there might be a packet loss/data loss.Best Regards,OV_Renesas
First of all I would like to thank you for the answers.
OV_Renesas said:It is not exactly clear to me what you have modified on the SPS SDK. Could you please share a code snippet of the changes you have made in order to send/receive data?
I didn't change the code, I just set a breakpoint to see if the data from the SmartConsole application to the DA14531 arrived correctly.
During these hours, I investigated further and found that the data seems to be arriving correctly, as you can see from the screenshot below.
After executing the code, everything should work fine, but I didn't receive anything at the console.
I checked the pin (also checking continuity with the tester) and the terminal setting, but everything should work fine, also because when I send something from the terminal to the SmartConsole, the message arrives correctly.
OV_Renesas said:The application will then divide the file you had selected into Chunks sizes that you set. It is not mandatory to use the exact length of the characteristics. Even if you use a higher chunk size, i.e. 500 or 600 bytes of data per chunk, then the L2CAP Protocol will start working. It is the BLE stack that will handle this and you will not have to do anything. Since BLE Specification allows only 251 bytes of data to be transmitted per packet, the L2CAP protocol recognizes when we have more data and it breaks those data into different packets.Please refer on the screenshot from a BLE Sniffer capture between DA14586 with SPS SDK and SmartConsole application when I sent over 251 bytes in one characteristic:
Sure, thanks. Other than that, I would also like to know if there is some sort of acknowledgement when the packet is transferred, if so, how it works. Checking the properties of the service I see that the "DSPS Server TX" property is set to Notify and "DSPS Server RX" is set to Write no response, so I was wondering how the application can actually know if a packet is lost.
Last question, if it is possible. I noticed that when I set a breakpoint, so when I stop a code execution, then the app automatically disconnects, even if I immediately restart the code execution, could you explain to me why? Is there a way to avoid this behaviour (I tried setting the default sleep to OFF, but nothing changed)?
Sorry for asking too many questions and thank you in advance.
Hi Giorgio,Thank you for the reply.
Giorgio said:After executing the code, everything should work fine, but I didn't receive anything at the console. I checked the pin (also checking continuity with the tester) and the terminal setting, but everything should work fine, also because when I send something from the terminal to the SmartConsole, the message arrives correctly.
Since you added a BKPT, the BLE connection was terminated and the UART interface was turned OFF. The data should be stored in the Rx buffer and it should be printed out at the next connection. However, if you are not able to establish a BLE connection the first time after a disconnect (i.e. bad signal) the data will be lost.
Giorgio said:Last question, if it is possible. I noticed that when I set a breakpoint, so when I stop a code execution, then the app automatically disconnects, even if I immediately restart the code execution, could you explain to me why?
During a BLE connection Central and Peripheral exchange packets constantly based on the connection interval. By setting a BKPT, we stop/halt the BLE core and it can no longer send/receive those packets (Empty PDUs). Since we are "messing" with the BLE core timings on send/receive, the central considers that the device is no longer there "listening" and it terminates the connection.Unfortunately, it is not ideal to debug with BKPT while you have established a BLE connection. You should use print statements or have a BLE Sniffer to capture the data being sent over the air.
Giorgio said:Other than that, I would also like to know if there is some sort of acknowledgement when the packet is transferred, if so, how it works. Checking the properties of the service I see that the "DSPS Server TX" property is set to Notify and "DSPS Server RX" is set to Write no response, so I was wondering how the application can actually know if a packet is lost.
The DSPS Server Rx/Tx characteristics have the Notify permission and do not sent any ACK to the other side.You can change this Permission to Indicate, but this would reduce the SPS Performance almost at 50%.Please refer here: 10. SPS Performance (renesas.com)Please also refer here: 3. Architecture (renesas.com)We are utilizing the BLE Flow Control mechanism. This helps with data loss when we want to receive data from a peer device. We are also utilizing the 4-Wire UART with Flow Control for data loss when we want to sent data to a peer device.Best Regards,OV_Renesas
Thank you for the replies, everything clear.
But still the main problem is not resolved yet.
OV_Renesas said:Giorgio said:After executing the code, everything should work fine, but I didn't receive anything at the console. I checked the pin (also checking continuity with the tester) and the terminal setting, but everything should work fine, also because when I send something from the terminal to the SmartConsole, the message arrives correctly. Since you added a BKPT, the BLE connection was terminated and the UART interface was turned OFF. The data should be stored in the Rx buffer and it should be printed out at the next connection. However, if you are not able to establish a BLE connection the first time after a disconnect (i.e. bad signal) the data will be lost.
This happens even when I don't set a BKPT. I only set the breakpoint after experiencing the problem to see if the message arrives correctly from the BLE to the DA14531, and it does, as you can see in the first screenshot. I think the problem is in the UART communication from the DA14531 to the terminal.
When I simply run the code without BKPT, the messages from the terminal to the SmartConsole arrive correctly, but when I send messages from the SmartConsole to the terminal, no text arrives.
I tried to use the oscilloscope to analyze the signal from the DA14531 to the UART terminal and I notice that:
Basically, I noticed that when UART hardware flow control is enabled, the CTS and RTS signals always remain at the same logical level. The fact that the CTS flag is always low makes sense because this probably tells that the terminal is always ready to receive, but what about the RTS? Could this be the problem?
Keep in mind that I never change the UART configuration, and no BKPTs were set to do the analysis with the oscilloscope.
Thank you
Hi Giorgio,Thank you for the reply and the clarifications.
Giorgio said:I'm currently using the development kit-pro
Is this your HW configuration?Could you please test this with Tera Term terminal as well?Because on my side, with the pre-compiled dsps_device_531.bin file I cannot replicate this issue.Best Regards,OV_Renesas
These are my connections.
I loaded into the Flash Code the "dsps_device_531.bin" binary image through the SmartSnippet Toolbox.
The terminal settings (Termite) are shown above. I also tried with Tera Term but still the same problem.
Everything seems to be correct, but the problem remains the same. Should I assume that the DA14531 is broken?
Giorgio said:Everything seems to be correct, but the problem remains the same. Should I assume that the DA14531 is broken?
This is not the DA14531 SoC but the DA14531MOD.Please use the below HW configuration:On J1 header you do not need to place the 5 first jumpers for the SPI Flash since the DA14531MOD has an integrated SPI Flash. If you place the headers on V_FL, MOSI, SCK,FCS,MISO you will use the integrated SPI Flash of the Dev Kit.Best Regards,OV_Renesas
OV_Renesas said:This is not the DA14531 SoC but the DA14531MOD
Yes, I know, i say it in the title, I then miss it for simplicity, my fault.
I found the correct configuration, now seems to work.
Just out of curiosity, why do I need the internal flash if I'm not using the DSPS configuration module?
According to this architecture, I don't understand why I need the internal SPI flash, which is only used for the configuration module.
Also, why change the UART configuration, and why was I able to receive messages but not send? Are the schematics of the boards available?
Hi Giorgio,Thank you for the reply.Let me try to answer your questions:My Setup: DA14531MOD Daughterboard and Dev Kit Pro.HW Setup:
I used Renesas SmartBond Flash Programmer to download the dsps_device_531.hex firmware into the DA14531MOD integrated SPI Flash (P25Q11U).I set up Tera Term with the following configuration:I opened the Renesas SmartConsole mobile application and I got the following results:
Giorgio said:Just out of curiosity, why do I need the internal flash if I'm not using the DSPS configuration module?
The Firmware will need to be in SRAM in order to be executed but when you remove the power consumption all the contents of the SRAM will be deleted since SRAM is a volatile memory and requires power to maintain the stored information. This is why we are using the integrated SPI Flash (you can also use an I2C EEPROM on a custom board). During boot, the ROM bootloader will search for all the available booting options to detect where the firmware is stored. It will then download the firmware into SRAM in order to be executed. If there is enough space on the SPI Flash you can also implement SUOTA (Software Update Over The Air) or add the DSPS Configuration Service/features.Please refer here for more information:AN-B-072: DA1453x Booting from OTP and Serial Interfaces (renesas.com)Please check section 5.1 BootROM Sequence.
Giorgio said:Also, why change the UART configuration, and why was I able to receive messages but not send? Are the schematics of the boards available?
The Dev Kit Pro supports the following Daughterboards: DA14531, DA14531MOD, DA14585, DA14586, DA14535 and DA14535MOD.Each Daughterboard have different GPIOs exposed on different headers that is why you will need to follow the correct HW configuration. You used the correct GPIOs for UART Rx but wrong configuration for the UART Tx.Regarding the Schematics:Please refer on the: UM-B-141: DA14531 SMARTBOND TINY MODULE Development Kit Pro Hardware User Manual (renesas.com)and onUM-B-114: DA14531 Development Kit Pro Hardware User Manual (renesas.com)On the Development Kit Pro Product page you can also download the Schematic, Gerber files etc.For the DA14531MOD Daughterboard please refer on its product page: DA14531MOD-00F1DB-P - SmartBond TINY DA14531 Bluetooth® Low Energy 5.1 System-on-Chip Module Development Kit Pro - Daughterboard | RenesasI hope the above clears things up.Best Regards,OV_Renesas