• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 20 replies
  • Subscribers 63 subscribers
  • Views 9588 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 220891
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to Run DTM on nRF52840 development kit using MT8852B?

New Guy

Hi all,


I have a nRF52840 development kit and flashed (I believed it flashed successfully) with direct test mode .hex file from SDK 15.2. What I facing was not able to run any test from MT8852B due to unable to get the unit address from the board. Did anyone tried to run DTM with MT8852B on nRF52840 DK ? Kindly advise

TQ

Parents
  • 0

    Hi,

     

    In order to get DTM running on any bluetooth tester, you would need to use other RXD and TXD pins when using the nRF5x development kit. This is because the UART is by default routed to the SEGGER IC on the devkit, so you will get two UART hosts conflicting the lines.

    If you go into the dtm/direct_test_mode/main.c file, you can change the defines for RXD and TXD in function uart_init().

    After changing these from the default GPIOs P0.06 and P0.08 (flip the kit over to see which GPIOs are unused), you can connect the chosen GPIOs to the bluetooth testers UART. Remember to use BLE 2-Wire when connecting to the Anritsu.

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    hi Hakan,

    regarding the Rx & Tx pin, if i only use the J3 usb port as the power source to the nRF52840 chipset, could this good enough to avoid the conflict as you mentioned?? in this case, do i still need to redefine the pin in the main.c file ??

    Another thing, i am using the dtm/direct_test_mode_pca10056.hex file instead of the dtm/main.c file as the source for the test. any different between them?? kindly advice if i am using the correct source code..

    tq

  • 0 in reply to Håkon Alseth

    Hi,

    Thanks again for the hex file, but still unable to communicate with the Anritsu. It show me "EUT disconnected" & "Warning: EUT control (0x56)" when i choose the rs232 (my level shifter is rs232 protocol) and ble2wire as the source.

    Just fyi, my setup is no problem because I tried the same setup with my previous project and it works !!

    Maybe there is some setting i need to modify from the Anritsu?? Current setting as below:

    - baud rate : 19200

    - parity: none

    - data length: 8 bits

    - stop bits: 1 bits

    - handshaking: none

  • 0 in reply to New Guy

    Hi,

     

    New Guy said:

    Maybe there is some setting i need to modify from the Anritsu?? Current setting as below:

    - baud rate : 19200

    - parity: none

    - data length: 8 bits

    - stop bits: 1 bits

    - handshaking: none

    These settings are good.

     

    Did you try the other one with different GPIOs to see if this works better?

    TXD should be high from the nRF (ie: P0.27), while RXD should be low (or pulled high when connected to PC). Could you verify this?

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi,

    Please see below signal.Yellow is probing at Rx (p0.26) while green is probing at Tx (p0.27). below signal is when i press to obtain the EUT address on Anritsu.

    best regards,

  • 0 in reply to New Guy

    Hi,

     

    All lines and responses (I cannot see the actual bytes going in/out) seem to be good.

    Can you send a picture of the anritsu PC setup? It is crucial that you are connecting with "Ble2Wire" and not any other mode.

    Some times I have seen issues connecting, where a reboot of the anritsu has solved the issue.

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hello Håkon,

    I'm facing the same issue as "New Guy" with the Anritsu tester and a nRF52832 devkit (straps SB23 and SB25 are cut and Tx and Rx are collected on TP6 and TP8 : P0.6 and P0.8)

    I observe the same signals on the scope. What is strange is that the response from the DTM software (the lower trace on the scope) is composed of 2 bytes at 19200 bds (1.04 ms) followed by two other bytes approximately 4 ms after. But according to DTM BLE spec (Vol 6 Part F chapt. 3.4), the answer should be only 2 bytes.

    When readind the code of DTM main.c, only two bytes are sent back by the chip at the end of the for loop :

    if (dtm_event_get(&result))
    {
    // Report command status on the UART.
    // Transmit MSB of the result.
    while (app_uart_put((result >> 8) & 0xFF));
    // Transmit LSB of the result.
    while (app_uart_put(result & 0xFF));

    Do you see where these two other bytes could come from ?

    Thanks.

Reply
  • 0 in reply to Håkon Alseth

    Hello Håkon,

    I'm facing the same issue as "New Guy" with the Anritsu tester and a nRF52832 devkit (straps SB23 and SB25 are cut and Tx and Rx are collected on TP6 and TP8 : P0.6 and P0.8)

    I observe the same signals on the scope. What is strange is that the response from the DTM software (the lower trace on the scope) is composed of 2 bytes at 19200 bds (1.04 ms) followed by two other bytes approximately 4 ms after. But according to DTM BLE spec (Vol 6 Part F chapt. 3.4), the answer should be only 2 bytes.

    When readind the code of DTM main.c, only two bytes are sent back by the chip at the end of the for loop :

    if (dtm_event_get(&result))
    {
    // Report command status on the UART.
    // Transmit MSB of the result.
    while (app_uart_put((result >> 8) & 0xFF));
    // Transmit LSB of the result.
    while (app_uart_put(result & 0xFF));

    Do you see where these two other bytes could come from ?

    Thanks.

Children
Related