hello
i am using the sps example to transfer data from a serial device via uart to the DA14580 and via ble to another DA14580 (with host_sps) and then via uart to the terminal in the PC
i am having a data integrity issue- this is what i get in the terminal (its just a small part of the stream but the swaps are accuring all along the data stream):
77 00 FB F1 03 00 84 03 B2 07
78 80 17 F2 03 00 84 03 B2 07
79 00 FF F183 00 84 03 B2 07
FA 00 11 F2 03 00 84 03 B2 07
7B 00 EF F1 03 00 84 03 B2 07
7C 00 FB F1 03 00 84 03 B287
as you can see i am getting a char swap in some of the charecters
there are swaps that "0" is swapped with "8" (which in binari is just one bit - "0" : 00110000 , "8" : 00111000 )
but some of the chars are completely different ("7" and "F" 00110111 , 01000110 )
i even tried to lower the transfer rate to 100kbit/s but its still happening
what can be the problem?
tnx
Hi roinovi,
The only occasion i can think of that this could happen is due to an untrimmed crystal. The crystal trimming value is provided by the software and is a generic value that most of the times works with all crystals. Although this should occur at the ending bits of the uart byte transmition. Are you experiencing the same problem when using the DSPS android or iOS application ? Besides that we dont have observed anything like this.
Thanks MT_dialog
hello
i am having this problem in the dsps ios/android app as well
also , there are chunks of data that are not transfering at all (regardless the board i am using-murata or dialog)
i saw that it has problems with data which is "00".
sometimes it doesnt transfer the value "00" and sometimes it doesnt transfer a data which is between 2 "00"
e.g "13 23 54 67 54 00 ed h5 3e 67 00 8g ad dd"
it will not transfer the "00 ed h5 3e 67 00"
so it will look like this "13 23 54 67 54 8g ad dd"
what can it be?
maybe something in the sending code?
this is really a problem because i cant use this ble module if my data is not transferring correctly
tnx
Hi roinovi,
We haven't observed any problems of data integrity at least on dialog's kits, the only occasion where something like this will occur is because of a false crystal value. Have you tried any other configurations on the DSPS application like removing sleep or changing the HW to SW flow control. I ve just tested you patern between a pro board and the DSPS application on android with a fresh downloaded fw all the data seem that are transfering ok. The configuration on the DSPS device was with extended sleep on and HW flow control with the appropriate modifications in hardware for the pro kit.
Thanks MT_dialog
hello
i have tried to removed the sleep but its the same
how do i disable sleep entierly?
now i took the default sps_device and burn it on the da14580 dialog evkt-b (so the crystal values should be ok)
我没有做任何代码和的变化phenomena i get is the same, some specific chars are getting swapped
e.g
0A 0D 36 00 F0 55 00 00 90 DC 01 00 30 63 03 00 DC 05 DC 05 DC 05 00 00 00 00 00 00 00 00 00 00 00 FE 00 00 00 FC
0A 0D 37 00 D8 59 00 00 78 E0 01 00 18 67 83 00 DC 05 DC 05 DC 05 00 00 00 00 00 00 00 00 00 00 00 FE 00 00 00 FC
0A 0D 38 00 C0 5D 00 00 60 E4 01 00 00 6B 03 00 DC 05 DC 05 DC 05 00 00 00 00 00 00 00 00 00 00 00 FF 00 01 80 FF
8A0D 39 00 A8 61 00 00 48 E8 01 00 E8 6E 03 00 DC 05 DC 05 DC 05 00 00 00 00 00 00 00 00 00 00 00 FF 00 01 80 FF
0A 0D 3A 00 90 65 00 00 30 EC 01 00 D0 72 03 00 DC 05 DC 05 DC 05 00 00 00 00 00 00 00 00 00 00 80 FF 00 01 00 FF
0A 0D 3B 00 78 69 00 00 18 F0 01 00 B8 76 03 00 DC 05 DC 05 DC 05 00 00 00 00 00 00 00 00 00 00 00 FF 00 01 00 FF
this 0->8 swapping is occuring once a while
this happens as well (should be all 21's but you can see the "A" instead of the 2)
21 "A1 21 21 21 21 21 21 21 21 21 21 21 21 21 "A1 21 21 21 21 21 21 21 21 21 21 21 21 21 21 "A1 21 "A1 21
there could be more but i wouldnt know so you see why its a big problem
could it be maybe because i am recieving data via uart and sending via ble at the same time?
hello
i saw in the forum another post like mine, with data not transfering ok:
http://support.dialog-semiconductor.com/dsps-hardware-flow-control-0
you didnt gave him an answer as well
could you please think of something that i can check to resolve this
thank you
Hi roinovi,
The customer in the post you mention was using an external processor to send data through the DSPS, when using an external proccessor things are more complicated and the truncation he was experiencing it might was due to a fault on his own proccessor or program and we can't test that.
Besides that, the DSPS should work out of the box without modify anything when it is used as a demo. About your problem i cant replicate it with an iOS and android or from a pc to pc connection and i ve used both basic and pro dev kit and send data simultanieusly with the series you ve indicated. Can you please share the exact settings of your test bench in case i am missing something (dev kits, sw settings, sending data)? Other than that since you are using basic kits and you are using an external FTDI can you please try with another FTDI in case that is causing you any trouble? Also make sure that you use the appropriate settings in your terminals (- the dsps doesn't use any special settings but make sure that - HW/SW flow control, whatever you ve set in the project, is set in the terminal options as well, 8bit data - no parity/1 stop bit). Also in a few days the DSPS on the SDK5 is going to be released, you can try the newer version and check if the issue persists.
Thanks MT_dialog
my set up is this
my device (mcu) is transfering data via uart (pins 4,7) to a dialog 14580 evkit, the 14580 is transfering this data to a murata p2ml3656 evkit which is connected to the pc (terminal)
on the dialog -> sps_device , on the murata -> sps_host
my device is sending serial data in 115k2 continuesly so the moment the buffer in the dialog gets full it send via ble the data
i think that the glitches are happening when the dialog is transfering via ble while recieving the serial data.
i tried to send serial data to the dialog every second and then send it via ble to the murata and there were no glitches thats why i believe that it has a problem recieving data via uart and sending data via ble at the same time
do you know of such a glitch?
furthermore, i want to send the data via ble only when i reach a certain string, i tried modifying the
void app_ble_pull (void)
{
static uint8_t rounds_waiting=0;
int read_amount;
if(tx_busy_flag == 0 && ble_flags.txAllowed == TRUE)
{
read_amount = app_item_count(&uarttoble_buffer);
if ((*(uarttoble_buffer.data_ptr + uarttoble_buffer.readIdx)) == 253)
if ((*(uarttoble_buffer.data_ptr + uarttoble_buffer.readIdx+1)) == 170)
{
// if (read_amount >= TX_WAIT_LEVEL || (rounds_waiting++) >= TX_WAIT_ROUNDS) buffer->data_ptr+buffer->readIdx
// {
// rounds_waiting = 0;
app_init_ble_tx();
// }
}
}
}
but it doesnt work , any ideas?
tnx
Hi roinovi,
Since you are using an external MCU to send the data there might be a drift between the UART clocks between your MCU and the 580 i suppose that you ve allready tried to lower your baud rate and the issue persists. Can you sent us a capture with a logic analyser between your MCU and the 580 with a faulty transaction to have a look. Alsoyou are experiencing the issue when you send from the android and receive the data on your MCU through the 580 or the other way around ? As far as i now we haven't observed any glitches while transfering data on both sides. Also as far as i can understand you ve made some changes to the DSPS application can you share the changes and the data patterns that you send to your devices as well ?
你想做什么我不相当stand so i suppose that you want to collect data until a specific character is received, please try to use the below snippet in the DSPS application, this should hold your stream until you press the "r" character for example.
void app_ble_pull (void)
{
static uint8_t rounds_waiting=0;
int read_amount;
if(tx_busy_flag == 0 && ble_flags.txAllowed == TRUE)
{
if((read_amount = app_item_count(&uarttoble_buffer)) > 0 && *(uarttoble_buffer.data_ptr + uarttoble_buffer.writeIdx-1) == 'r')
{
if (read_amount >= TX_WAIT_LEVEL || (rounds_waiting++) >= TX_WAIT_ROUNDS)
{
rounds_waiting = 0;
app_init_ble_tx();
}
}
}
}
Thanks MT_dialog
hello
1) i wanted to see if the problem is in the uart transmition or the ble so i connected my mcu's tx to pin 4 in the evkit and i saw that my data (from the mcu) is transfering perfectly via uart to the evkit and to the terminal so i dont think the problem is in the uart.
this is one block of data i send periodically every second from my mcu via uart to 580 :
55 00 01 02年03 04 05 06 07年08年09年0 0 0 b c d 0 e 0 f10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD AA
above is a capture from the terminal while connecting my mcu's tx to pin 4 on the 580 and listening in the terminal to the 580 uart com, the data is transfering perfectly.
2) my setup is : my mcu ---- uart>>> dialog 580---ble>>>murata p2ml3656---uart>>>pc(terminal)
i have also saw the glitches when i recieved the data to the dsps app on ios and android (so i dont think its the changes i ve made in the sps_device which were only in the app_ble_pull in the ble transmition initiator if, e.g if((read_amount = app_item_count(&uarttoble_buffer)) > 0 && *(uarttoble_buffer.data_ptr + uarttoble_buffer.writeIdx-1) == 'r'))
i ve also changed the size of the buffer because i need to hold 1536 bytes in the uarttoble_buffer and then send via ble in order to not send while recieving uart
#define RX_BUFFER_ITEM_COUNT (int) 1700
#define RX_BUFFER_ITEM_SIZE (uint8_t) 1 //**do not change item_size**
#define RX_BUFFER_HWM (int) 1190 //70%
#define RX_BUFFER_LWM (int) 510 //30%
this is how i get the data while transfering it via ble (this capture is from terminal) :
55 00 01 02 03 0485 0687 0889 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B9C 1D9E 1F 20 21 A2 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2FB35 0 31 32 33 34 36 37 38 39 3 3 3 b c 3 d f C0 3 e41 42 43 44 45 46 47 48 C9 4A 4B 4C 4D 4E CF 50 51 52 53 54 55 56 D7 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D EE 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 85 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 94 15 16 17 18 19 9A 1B 1C 1D 1E 9F 20 21 22 23 24 A5 26 27 28 29 2A 2B 2C 2D AE 2F 30 31 32 33 34 35 36 B7 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 C9 4A 4B 4C 4D 4E 4F 50 51 52 D3 54 55 56 57 58 59 5A 5B DC 5D 5E 5F 60 61 62 63 64 65 E6 67 68 69 6A 6B 6C ED 6E 6F 70 71 F2 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 84 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D9E 1F 20 21 22 23 24 25 26A7 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 B5 36 B7 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A CB 4C 4D 4E 4F 50 51 52 53 54 D5 56 57 58 59 5A 5B 5C 5D 5E 5F 60 E1 62 63 64 65 66 67 68 E9 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 86 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 A5 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 B8 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 C6 47 48 49 4A 4B 4C 4D CE 4F 50 51 52 53 54 55 56 57 58 59 DA 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 F1 72 73 74 75 76 77 78 79 7A FB 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 92 13 14 15 16 17 18 19 9A 1B 9C 1D 9E 1F A0 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E BF 40 C1 42 43 44 C5 46 C7 48 C9 4A CB 4C 4D 4E 4F 50 51 52 D3 54 55 56 57 58 59 5A DB 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 F9 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 81 02 03 04 05 06 07 08 09 8A 0B 8C 0D 0E 0F 10 91 12 93 14 95 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 B3 34 35 36 37 38 39 3A 3B 3C BD 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F D0 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D DE 5F 60 61 62 63 64 65 66 67 68 69 6A 6B EC 6D EE 6F 70 71 72 73 74 F5 76 77 78 79 FA 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD AA
the data is supposed to be numbers in ascending order (starting with 55) and as you can see there are glitches
in binary, the glitch is in the first bit e.g: instead of 05 i get 85 which in binary is : 10000101 instead of 00000101
the same about 1C and 9C : 10011100 instead of 00011100 etc
我怀疑这祝福和时发生uart are transmitting simultaneously, can it be?
i tried to send only when there are no uart transmition so i did:
if ( (uart_flags.txAllowed==TRUE )
but there were still glitches,
3) in regards to collecting data via uart until a specific charecter is recieved and then sending via uart (you were correct, this is what i am trying to do)
i tried what you sugested :
void app_ble_pull (void)
{
static uint8_t rounds_waiting=0;
int read_amount;
if(tx_busy_flag == 0 && ble_flags.txAllowed == TRUE)
{
if((read_amount = app_item_count(&uarttoble_buffer)) > 0 && *(uarttoble_buffer.data_ptr + uarttoble_buffer.writeIdx-1) == 'r')
{
if (read_amount >= TX_WAIT_LEVEL || (rounds_waiting++) >= TX_WAIT_ROUNDS)
{
rounds_waiting = 0;
app_init_ble_tx();
}
}
}
}
it works
tnx
Hi MT,
I'm contacting you on behalf of Roi as Dialog local disti in Israel.
We really need your help to solve the issue that keeps pooping up.
Roi is still getting glitches on the data he receives over the BLE interface.
They isolated the problem to the following scenario:
单片机——> (UART)——> DA14580DEVKT-B——> (bie)——>村田国防部ue using Dialog
Roi has described the glitches in above communication.
Few points to consider:
MCU - EFM32
Using the internal MCU oscillator.
When testing HyperTerminal to HyperTerminal via UART to BLE and back to UART no glitches occurred.
Please advise if you can think of a solution.
Thanks in advance
Dan
Tritech
Hi roinovi, Bendaa,
We are working on your issue and try to figure this out. When you say testing from Hyper Terminal to Hyper terminal you mean from a pc to pc connection the incident doesn't occur ? For the data to be altered during the BLE transfer its unlikely and besides the UART or a logical error in the code i dont see anything else is possible. We would like you to provide a logic analyser or an oscilloscope capture transfering data from the 580 to the MCU and from the MCU to the 580 with 0xaa or 0x55 in order to check the clocks of the UART on the MCU also we would like to provide a capture with the error case in order to figure it out.
Thanks MT_dialog
yes, i mean from pc to pc the incident doesnt occure.
furthermore, as i stated before, i wanted to see if the problem is in the uart transmition so i connected my mcu's tx to pin 4 in the evkit (which is also uart rx) and i saw that my data (from the mcu) is transfering perfectly via uart to the evkit and to the terminal. so can it still be a uart problem?
can it be something in the sps code? maybe something with managing the data in the buffer?
when you try to simulate the problem, try to transfer 1536 bytes every second (this is my system)
Hi roinovi,
We dont think that is a code issue or the changes you ve made in the code, we also dont think that the changed buffers has something to do with it. We suppose that is a clock issue between the MCU you are using and the 580. So, we would like the captures mentioned in the previous post to make sure. Flipping bits sounds more like a timing or an electrical problem and if was something in the code i suppose that it should occur in a pc to pc connection. I ve tried to simulate your problem using the exact settings that you 've mentioned above (changed the definesRX_BUFFER_ITEM_COUNT, RX_BUFFER_ITEM_SIZE, RX_BUFFER_HWM, RX_BUFFER_LWM on the device side and sent the exact data that you 've pasted) i haven't achieved in reproducing the problem on two pc connection and we dont have the external MCU you are using.
Thanks MT_dialog
hello
i tried to decrease my mcu's uart rate to 38400 and the data transferred ok all the way (uart ble uart)
what can be the reason that in 115200 the flipping bit occures?
is there something that can be done?
Hi roinovi,
I though that you ve tried to lower the baud rate and the incident still occured, in that case the reason, and thats why i ve wanted to check the data rate of your MCU, is that the 580 uart can't achieve the 115200 rate, the actual baud rate of the 580 is about 111111.111, and cant keep up with your external MCU, so every once and a while the sampling of the data is delayed and you get this flipping bit incident.
Thanks MT_dialog
有另一个模ule that can achieve 115k uart?
what is the maximum rate of the 580?
Hi roinovi,
In all the 58x family this is the baud rate it can be achieved for the 115200 standard. As i mentioned in my previous post the data rate that 580 can achive is about 111.111 rate. Please check the uart_sps.h in order to have a look how to calculate the exact baud rate on the 580.
Thanks MT_dialog
hello
if i connect the 580 module to an external crystal 32kHz will i be able to get a more accurate baude rate?
closer to the 115200 standart?
Hi roinovi,
No, i am afraid that this isn't going to change anything, the XTAL32 is only used for the low power clock and not for generating the clock in the UART.
Thanks MT_dialog