Tx frequency does not change when using mbt le_transmitter_test

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

On custom hardware using a BCM20736 we boot the BT device and run the mbt tool (SDK v2.2.2)

When we issue the le_transmitter_test command, the output is always at ~2450 MHz regardless of what transmit channel we specify.

When we issue the set_tx_frequency_arm command, the output is also always at ~2450 MHz regardless of the tx_frequency we specify.

We do notice that the output does not look stable... wondering if there are some PLL locking issues.

Need some guidance on how to debug this issue. Thanks

1 Solution
Anonymous
Not applicable

Thanks for persisting with this... really appreciate it.

However, it turns out that our problem was that we were not in Programming mode... since we had our I2C to the EEPROM disabled we weren't even loading our configuration (I think).

After switching to not disabling our I2C and performing reset with HCI UART Rx = 1 i.e. in Programming mode, we now see the channel changing per the MBT command issued.

View solution in original post

8 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Have you reviewed the following: Manufacturing Bluetooth Test Tool Application Note (SDK 2.x and TAG3 Board)

Have you tested the MBT tool on one of our evaluation boards with one of the default programs in the SDK?

Can you confirm that the HCI UART is functioning properly on your custom board? My guess is that the HCI UART on your board is not coming up in the correct mode.

The CHANGELOG.txt file of SDK 2.2.3 states there were some RF improvements, but I don't know the extent of them.  I would certainly install that SDK just to give it a try.

The recommendation to try one of the Broadcom boards is a good idea as it demonstrates what to expect, and that your equipment setup is wokring.

Looking at the source code for the MBT utility, there appears to be printf() statements as the test progresses - I assume you are not seeing any errors, and the code-flow is correct?  Stated differently:  Are you seeing the "LE Transmitter Test running, to stop execute mbt le_test_end COMx" message?  Lastly, the instructions state to stop one test (via le_test_end or reset) before starting another... did you do that?

What MBT.exe version (the operating system) are you running on?  What equipment are you using and describe its setup please.

0 Likes
Anonymous
Not applicable

Thanks for the prompt responses.

We have reviewed the App Note carefully and the HCI UART is functioning correctly with the MBT utility returning the correct responses per the App Note. When we start the  transmitter test we see the "LE Transmitter Test Running" message and we see the transmitted waveform on our test equipment. We observe the Tx power increasing / decreasing when we change Tx power. This is true of both le_transmitter_test and set_tx_frequency_arm. We are running MBT on a Windows 7 PC. I will get you details of the test equipment (I am remotely supporting this testing)

The only thing we have not tried is a Broadcom board...

Another related question we have wondered about:

We are bringing the BCM20736 out of reset with the HCI UART Rx set to low, and the I2C to the EEPROM disabled to inhibit our own application from running. Is that the correct thing to do?

0 Likes

When RESET de-asserts, the romcode samples the HCI_UART_RX pin.  If HCI_UART_RX is asserted high, the device enters programming mode - and the MBT.exe utility can successfully talk to the 20736.

This example shows the Broadcom 'TAG3' eval board with HCI_UART_RX high during RESET de-assert:

~Win32>mbt reset COM52

Sending HCI Command:

0000 < 01 03 0C 00 >

Received HCI Event:

0000 < 04 0E 04 01 03 0C 00 >

Success

If the HCI_UART_RX pin is low, the Romcode reads the NVRAM contents.   If present, and the checksum matches, the application is downloaded from NVRAM into RAM and then executed.

If no application is present, or the checksum fails (your case), the device enters recovery mode (must reprogram with the SDK tools, e.g. chipload).  I don't have a way to test if MBT.exe can talk to it when in recovery mode... sorry.

<<We are bringing the BCM20736 out of reset with

<<<the HCI UART Rx set to low, and the I2C to the

<<<EEPROM disabled to inhibit our own application

<<<from running. Is that the correct thing to do?

I don't think this is what you want to do if you're trying to run MBT... because your method puts the device into Programming/Recovery mode.

<<<When we start the  transmitter test we see the "LE Transmitter Test Running"

<<<message and we see the transmitted waveform on our test equipment.

<<<We observe the Tx power increasing / decreasing when we change Tx power

<<<When we issue the le_transmitter_test command, the output is always

<<<at ~2450 MHz regardless of what transmit channel we specify.

<<<When we issue the set_tx_frequency_arm command, the output is

<<<also always at ~2450 MHz regardless of the tx_frequency we specify.

I may have mis-interpreted your original problem.... the MBT tool is running, and the Transmitter is on... the problem seems that it's always locked onto ~2450 MHz???

I don't have a spectrum analyzer but will see if I can get somebody (who does) to run the simple test...

Anonymous
Not applicable

Thanks...

Yes... "the MBT tool is running, and the Transmitter is on... the problem seems that it's always locked onto ~2450 MHz"

I'd appreciate it if you can try and replicate...

Sorry but I did get a little confused about what mode the chip should be in to run MBT.

Are you saying that I can run MBT even if my BLE application is loaded (from NVRAM) and running?

0 Likes

Programming Mode is what's needed.  Not Application Mode.

I don't have a spectrum analyzer, but asked one of my colleagues if they could do the test for me.  Here are the instructions I gave them.... anybody else have (an analyzer and) ten minutes to run the test for us?

Using a TAG3 Evaluation board, and the SDK 2.2.2 MBT.exe

  1. ~WICED-Smart-SDK\Tools\mbt\win32>mbt reset COM99
  2. ~WICED-Smart-SDK\Tools\mbt\win32>mbt le_transmitter_test COM99 2 10 4
  3. Make note of the carrier Frequency…
  4. Terminate the test with ~WICED-Smart-SDK\Tools\mbt\win32>mbt le_test_end COM99

Now test the Transmitter at a different channel:

  1. ~WICED-Smart-SDK\Tools\mbt\win32>mbt reset COM99
  2. ~WICED-Smart-SDK\Tools\mbt\win32>mbt le_transmitter_test COM99 8 10 4
  3. Make note of the carrier Frequency…   did it move as expected?
  4. Terminate the test with ~WICED-Smart-SDK\Tools\mbt\win32>mbt le_test_end COM99

ps – if MBT.exe fails to move the transmit frequency, can you try with MBT.exe from SDK 2.2.3?

0 Likes
Anonymous
Not applicable

Thanks for persisting with this... really appreciate it.

However, it turns out that our problem was that we were not in Programming mode... since we had our I2C to the EEPROM disabled we weren't even loading our configuration (I think).

After switching to not disabling our I2C and performing reset with HCI UART Rx = 1 i.e. in Programming mode, we now see the channel changing per the MBT command issued.