Closed mohamed-elsabagh closed 6 years ago
That firmware uses a 1M baudrate, as the 1m in the name signifies.
sorry I miss typed the wrong firmware version, I am using the 1152K firmware and I am facing the mentioned behavior
Hi @mohamed-elsabagh , the firmware connectivity_2.0.1_115k2_with_s132_5.0.hex
you are using is for v5. But the current pc-ble-driver-py is only supporting v2 and v3 now.
thanks so much but where can I find the right version of firmware?
I apologize I used this http://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF52832 firmware, v3 and v2 and I still have the same problem
I used the mentioned firmware, but still getting the same behavior, is there a special hardware connection I should connect my nordic chip so that it can work, I am just connecting TX ,RX, DTR, CTS between nrf52 dvk and my usb2uart, is there a special pin or port should be connected to a certain level?
I am still trying to make this work but still no lick, I notice something strange according to this page here https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v12.0.0%2Fser_phy_uart_page.html&cp=4_0_0_3_2_2_2 and https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v12.0.0%2Fser_phy_uart_hci_page.html&cp=4_0_0_3_2_2_3
the first 2 bytes are the header and they contains the length of the payload bytes, and from the logic analyzer image I sent on my first post this is the sequence of bytes sent from the python script on UART
0xC0 0x00 0x05 0x00 0xFB 0xC0, ...
so does this means that the upcoming bytes for the first command is 192 bytes, because the python library is definitely not sending 192 bytes but is sending 4 bytes in the payload, so maybe that's why the nrf52 is not responding
Hi, to clarify, you have linked to documentation of two different serialization transports, Raw and HCI. Raw transport uses a two byte header, though HCI transport uses SLIP (0xC0) and a four byte header. There is no length field in HCI transport, instead SLIP is used to tell when a packets starts and ends. pc-ble-driver uses HCI transport.
To answer your previous question, it is correct that you need TX, RX, DTR and CTS. No other lines are needed. It is however crucial that the flow control operates correctly, or you'll quickly end up with lost bytes. Getting the hw flow control correct is often the biggest challenge when using other serial2usb converters.
so the packets sent over UART are correct, so I can't figure out where is the problem, I tried connecting CTS and RTS to ground and still can't get any response from the board, I am using BT832X from fantsel
I'm not sure why things are failing with your setup. Supporting custom board setups are somewhat outside the scope of this issue tracker. I advice you to ask about your issue on devzone in addition. Also, it could be worthwhile to get pc-ble-driver running with a nordic devkit and observing how a working uart communication operates.
I lowered the optimization level on keil, flashed the firmware and run the C examples and I can now see some response from the nrf52 board, thanks
That's good to hear. Thanks for the update.
I flashed Nordic soft device connectivity_2.0.1_115k2_with_s132_5.0.hex into my NRF52 and I am trying to connect from my Ubuntu using Boost ver 1.63 When I run advertiser example code I can see on my logic analyzer that my Ubuntu machine is trying to send characters with baudrate 1152K but I never get response from my NRF52 I am not sure what's going on wrong here