• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 29 subscribers
  • Views 2191 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Issue's connecting HC-06

g.petrusevicius
Intellectual 370 points

Hello,


I have issue connecting to TM4C123GXL bluetooth module HC-06. It's connect's, but then I send some letter like 'j' I get back 'H'.. If I press like 's' in terminal I get 'b' but in most letter's press casses I get back just '@'..

Bluetooth module working great, I have tested it with my Arduino board with baud rate 9600 8,n,1. So i guess it's launchpad issue... Testing with SENA BTerm apps in my phone.

Code:

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "driverlib/debug.h"
#include "driverlib/fpu.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/pin_map.h"
#include "driverlib/rom.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"

#ifdef DEBUG
void
__error__(char *pcFilename, uint32_t ui32Line)
{
}
#endif

//*****************************************************************************
//
// The UART interrupt handler.
//
//*****************************************************************************
void
UARTIntHandler(void)
{
    uint32_t ui32Status;
    uint8_t cThisChar;
    //
    // Get the interrrupt status.
    //
    ui32Status = ROM_UARTIntStatus(UART1_BASE, true);

    //
    // Clear the asserted interrupts.
    //
    ROM_UARTIntClear(UART1_BASE, ui32Status);

    //
    // Loop while there are characters in the receive FIFO.
    //
    cThisChar = UARTCharGet(UART1_BASE);

    //
    UARTCharPut(UART1_BASE, cThisChar);

        //
        // Blink the LED to show a character transfer is occuring.
        //
    if(cThisChar == 'H') //press m
    {
        GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_PIN_2);

        //
        // Delay for 1 millisecond.  Each SysCtlDelay is about 3 clocks.
        //
        SysCtlDelay(SysCtlClockGet() / (2000 * 3));

        //
        // Turn off the LED
        //
        GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 0);
    }

}

int
main(void)
{

    ROM_FPUEnable();
    ROM_FPULazyStackingEnable();

    //
    // Set the clocking to run directly from the crystal.
    //
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
                       SYSCTL_XTAL_16MHZ);

    //
    // Enable the GPIO port that is used for the on-board LED.
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

    //
    // Enable the GPIO pins for the LED (PF2).
    //
    ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2);

    //
    // Enable the peripherals used by this example.
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART1);
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

    //
    // Enable processor interrupts.
    //
    ROM_IntMasterEnable();

    //
    // Set GPIO A0 and A1 as UART pins.
    //
    GPIOPinConfigure(GPIO_PB0_U1RX);
    GPIOPinConfigure(GPIO_PB1_U1TX);
    ROM_GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);


    ROM_UARTConfigSetExpClk(UART1_BASE, 16000000, 9600,
                            (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                             UART_CONFIG_PAR_NONE));

    //
    // Enable the UART interrupt.
    //
    ROM_IntEnable(INT_UART1);
    ROM_UARTIntEnable(UART1_BASE, UART_INT_RX | UART_INT_RT);

    while(1)
    {
    }
}

Maybe you guys have some minds about that...

  • 0
    Guru 47900 points

    Not everyone here would immediately recognize your, "HC-06 descriptor."  (and that's your advertisement - or subject)

    KISS always best for my group's simple minds.  Should not your first order of business be the establishment of reliable serial communication?  This usually is quickest/easiest accomplished via connection (abide by proper signal levels) between MCU and a PC's terminal program.  Only when that's up/running correctly should you add the challenge of another device...  (Bluetooth - your case)

    We note that you inflict a delay upon the UART's interrupt service.  Yes your desire for a performance indicator is sound - but such can be achieved outside the interrupt service.  (that service - most always should be short/sweet!)

  • 0 in reply to cb1
    Guru 26105 points

    Hi, 

    @Gytis, you are a victim of both speed and copy/paste - your original file mention " // Loop while there are characters in the receive FIFO." and the loop was completely removed, mainly UARTCharAvailable() which has its role in communication - so your program is able to loose characters. And this is not all: a delay loop inside a receiving UART is not acceptable, same reason. Also, the led is not blinking if enabled for one or two milliseconds - eye inertia is operating, and at least 30 ms will be a good start value, count on 50...100, and of coarse outside interrupt.

    Petrei 

  • 0 in reply to Petrei
    Guru 47900 points

    Petrei said:
    you are a victim of both speed and copy/paste

    Law school forces me to describe poster as, "perp" not victim...  (speed - minus strict "attention to detail" - provides fast road to disaster...)

    Continue in the belief that, "Proof of basic peripheral operation" should precede any more complex, MCU attachments...

  • 0 in reply to cb1
    Intellectual 370 points

    I have used UART0 connected with my PC Terminal and everything work fine. I get right characters and saw LED blink.

  • 0 in reply to g.petrusevicius
    Guru 47900 points

    Gytis Petrusevi��ius said:
    I have used UART0 connected with my PC Terminal and everything work fine.

    That's good - but how relevant is it to your, "new attachment" which employs UART1?

    Does not UART0 use, "special care/handling" to enable communication back to your PC?  (i.e. talks back to the PC's USB port via some ICDI means)  When you switch to UART1 - have you the same connection means and/or media?

    For a proper test - should not you attempt MCU to PC serial communication via UART1?  (realize - you've not done that - your test via UART0 offers little comfort {other than general set-up/config code's correctness})

    You must properly mate the required signal levels of the Bluetooth device to those of the MCU.

    I'd hazard the guess that as you've got "some - yet uncertain" communication results - you may have a "common ground" issue.  (i.e. Bluetooth device's ground must connect (tie) to MCU board's ground)  Has that been (recently) checked/verified?

  • 0 in reply to cb1
    Intellectual 370 points

    Yes, ground is really tie connected. So I don't know what else I can do...

  • 0 in reply to g.petrusevicius
    Guru 47900 points

    Gytis Petrusevi��ius said:
    I don't know what else I can do...

    You may consider the description of UART1's connection to your remote device.  (proper schematic or even "back of envelope/napkin scan" would work)

    Also - have you tried to communicate with the (more basic) PC via UART1?  (we know that works via UART0 - but that's a different beast - as I've labored to explain.)

    Wise also for you to confirm that sending the same character - slowly (say, second between repetitions) yields the same output at your remote.  Identify & describe both the character the MCU transmits (repeatedly) and that which the remote receives.  Tell us if that character changes - and be sure to identify both the character transmitted (same character, repeatedly) and that received - exactly...  (this may further aid diagnosis)  We suggest sending "A".

    And - of course - double/triple check that baud-rate, # of bits (data & stop), parity and NO Hardware Flow Control!   Like your use of 9600 baud - anything faster adds challenge - not of interest at this troubleshooting stage...

  • 0 in reply to cb1
    Intellectual 370 points

    I think I solved the problem. It seems working good for now!!


    To code, I added line

    GPIOPadConfigSet(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1, GPIO_STRENGTH_4MA, GPIO_PIN_TYPE_STD_WPU);


    So maked Pin Pull up and work's good!!

  • 0 in reply to g.petrusevicius
    Guru 47900 points

    While you "think" you've solved it - consider this: (copy/pasted from file, "gpio.c")

    GPIOPinTypeUART(unsigned long ulPort, unsigned char ucPins) {    

    // Check the arguments.    

    ASSERT(GPIOBaseValid(ulPort));

     // Make the pin(s) be peripheral controlled.    

    GPIODirModeSet(ulPort, ucPins, GPIO_DIR_MODE_HW); 

    // Set the pad(s) for standard push-pull operation.    

    GPIOPadConfigSet(ulPort, ucPins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    Thus - your "fix" culls you from the (driver lib) "herd" - does it not?  Is that wise?  And - if you can "fix" the driver lib - why "stop" at this function - alone?

    Suspect that another change (or changes) brought UART1 to life - not your "over-ride" of the driver lib's handling of the UART config.  (driver lib long worked for UART0-UARTn - for countless other users - absent any such "addition"...)