Mindtree SDK Supported Baudrates

Fred,

1) In addition to 115200, 921600 baud are also supported. The 921600 baudrate is only supported when the CPU is configured to operate at 25MHz. You can change the defines in the SDK to operate at 25MHz and run the BT device at 921600 baud.

2) The EZ430-RF2560 is hardware limited in the programmer/emulator board to 9600. You could bypass this by building your own USB to UART bridge and connect the EZ430. Yes, there are buffers which you are using since you are using the UART bridge code modification.

Regards,

Gustavo

Gustavo,

I haven't been able to get the 115200 to work. I changed line 85 of haal_usb.c to "halusb_set_baudrate(SDK_BAUDRATE_115200);".

Is there anything else that I need to change to make this work? Does the UART_TIMER_DELAY on line 28 of user_task.c need to be changed?

What is the reason that the other baud rates are not supported? Can this be overcome or is it a limitation of hardware? I would like to be able to use the full range of baud rates.

Thanks

Fred

Fred,

Are you trying to comunicate with the EZ430 stick over 115200 link? If this is the case, it will not work. As gustavo mentioned, there is a 9600 baud rate limit of the ez430 stick that the cc2560 is plugged into.

If you want to communicate via 115200, you would have to use a different USB/serial interface to communicate with the msp430bt5190 on the cc2560 board.

-Jason

Hi Jason,

I'm not using the EZ430 stick, I am connected directly to the MSP430 UART lines. Do you know why the full suite of baud rates aren't supported in the Mindtree stack?

-Fred

Fred, can you clarify which baud rate you are speaking of?

There are three baud rates in play here.

1. Baud rate in and out of the MSP430 to the outside world.

2. Baud rate between the MSP$30 and the PAN1315 module.

3. Baud rate of the Blue tooth radios.

If you look at msp430_uart.c at the UART init program, you will see that the switch settings is not setup to decode for the other values for the host UART interface.

-Jason

Hi Jason,

This is my impression of the definitions of the different rates you mention, can you verify that this is correct? I believe that each of these need to be equivalent in order to function?

1. Baud rate from MSP430BT to the outside world (UART) is defined by halusb_set_baudrate(unsigned long int baudrate) on line 85 of hal_usb.c 

2. Baud rate between the MSP430BT and the CC2560 / PAN1325 is defined by BT_UART_CONFIG_BAUDRATE on line 84 of sdk_bluetooth_common_config.h

3. Baud rate of the Bluetooth radio is defined by RFCOMM_DEFAULT_PORT_BAUD_RATE on line 69 of BT_rfcomm_api.h

I see that the switch statements are not set up for other rates. If I set up registers in the switch statements to handle the other rates, and I correctly set the 3 items above to equal values, it should work?

I would like to verify the functionality using a UART loopback test. Have you ever done this? I tried connecting P3.4 (RXD) to P3.5 (TXD) on the battery board that accompanies the EZ430 kit, but according to my scope, both the TXD and RXD pins remain at logic 0 no matter what data I send acoss through a terminal emulator. I tried a 10k pullup to Vcc on TXD, but this didn't help. Any thoughts?

Thanks

Fred

Fred,

Is there a specific reason why you need a different baud rate? We recommend that you use the standard baudrates that have been throughly tested with the SDK, unless you have a very particular requirement for different baudrates.

Which UART are you trying to verify using loopback? I believe the UART module itself includes a loopback feature itself. Look at page 657 of SLAU208I, the family user's guide.

Regards,
Gustavo

Hi Gustavo,

Where do you think would be the appropriate location to modify the UCA2STAT register to access the loopback feature? I have tried the folowing two lines (individually, not at the same time), at several locations in the SDK code (user_task.c, main.c, etc.), but each has caused the device to enter error mode. Maybe I'm not doing this correctly?

*(bt_uart_config.uart_reg_ucaxstat) |= UCLISTEN;  /* set UART to loopback mode */

OR

UCA2STAT |= UCLISTEN;       /* set UART to loopback mode */

Fred

Fred,

It depends. If you expect to create a simple application that tests the UART and is separate from the actual applicaiton, then just in the main would suffice.

However, if you want to add that test to the software and have it run as a diagnostic, then perhaps in the initialization of the UART it could test it and then set it correctly for normal operation.

Regards,
Gustavo