I'm attaching to a BC127 from Blue Creations.

The board is here: https://learn.sparkfun.com/tutorials/understanding-the-bc127-bluetooth-module?_g...

I upgraded the firmware from the shipping to version 6.1.2, when all heck broke loose 

What was happening is, it looks like there's no CR's ever sent on the response of commands. For example, here's what is logged and received by Visual Micro's COM port: 

0000 02d0 4d 3d 4f 46 46 20 4f 46 46 20 30 20 4f 46 46 20 M=OFF OFF 0 OFF
0000 02e0 4f 46 46 20 4f 46 46 20 4f 46 46 20 4f 46 46 4d OFF OFF OFF OFFM
0000 02f0 55 53 49 43 5f 4d 45 54 41 5f 44 41 54 41 3d 4f USIC_META_DATA=O
0000 0300 46 46 4d 55 53 49 43 5f 4f 4c 44 5f 41 56 52 43 FFMUSIC_OLD_AVRC
0000 0310 50 3d 4f 46 46 4e 41 4d 45 3d 42 43 2d 30 34 33 P=OFFNAME=BC-043
0000 0320 35 34 42 4e 41 4d 45 5f 53 48 4f 52 54 3d 42 43 54BNAME_SHORT=BC
0000 0330 34 33 35 34 42 50 49 4e 3d 30 30 30 30 50 52 4f 4354BPIN=0000PRO
0000 0340 46 49 4c 45 53 3d 32 20 30 20 32 20 30 20 32 20 FILES=2 0 2 0 2

I thought maybe there was a new delimiter command or something. I contacted Blue Creations tech support, and they said "you have to ensure CR is turned on in your terminal" (sigh ... after I'd explained it was the response TO the terminal, not commands FROM the terminal that were messing the CR's).

Now, after some debugging, I found Visual Micro's terminal shows no apparent CR's with firmware 6.1.1 and 6.1.2, but does work properly with 5.6 RC20.

Now here's the weird thing - I went and used putty, and putty worked CORRECTLY. Here's a similar hex dump from Putty - CR's are recieved between lines, but NOT in Visual Micro. Everything else seems to work!

Any ideas?

0000 0420 30 20 32 20 31 20 32 20 31 20 30 20 30 20 31 20 0 2 1 2 1 0 0 1
0000 0430 30 0d 52 45 4d 4f 54 45 5f 41 44 44 52 3d 30 30 0.REMOTE_ADDR=00
0000 0440 30 30 30 30 30 30 30 30 30 30 0d 53 50 50 5f 55 0000000000.SPP_U
0000 0450 55 49 44 3d 30 30 20 30 30 20 31 31 20 30 31 20 UID=00 00 11 01
0000 0460 30 30 20 30 30 20 31 30 20 30 30 20 38 30 20 30 00 00 10 00 80 0
0000 0470 30 20 30 30 20 38 30 20 35 46 20 39 42 20 33 34 0 00 80 5F 9B 34
0000 0480 20 46 42 0d 53 53 50 5f 43 41 50 53 3d 33 0d 54 FB.SSP_CAPS=3.T
0000 0490 57 53 5f 43 4f 4e 46 49 47 3d 4f 46 46 20 31 20 WS_CONFIG=OFF 1
0000 04a0 32 0d 55 41 52 54 5f 43 4f 4e 46 49 47 3d 39 36 2.UART_CONFIG=96
0000 04b0 30 30 20 4f 46 46 20 30 0d 55 53 42 5f 48 4f 53 00 OFF 0.USB_HOS
0000 04c0 54 3d 4f 46 46 0d 56 52 45 47 5f 52 4f 4c 45 3d T=OFF.VREG_ROLE=
0000 04d0 31 0d 4f 4b 0d 1.OK.

So, is there some weird timing problem, does Visual Micro only look for LF's and not CR's, or what?

I really want to use Visual Micro's terminal port, makes it easier to mix debugging / programming, etc. But, this bug is killing me as the screen doesn't even refresh unless I poke it with some more commands or something.

Same thing happened.

What's weird, is that Visual Micro isn't even logging the CR's. In looking at it, I guess it makes sense, something is stripping them out - the CR's don't even go to the screen.

My guess is the bug is that CR's are stripped out by themselves by VM; if a CR/LF pair is found, then that's echoed to the screen. Oddly, the buffering seems to be off also; if I don't click in the VM terminal window it won't update, even though I know the characters have been sent. 

For now, I'll use putty at least I know what's going on. Putty also has a way to force a LF. Using Putty, all the response goes on one line, overwriting the previous, so that's how I found what was going on.

The tech support guy at blue creations quit talking to me after he said "the BC127 is sending CR's". I guess he was right but it didn't look like it on the screen - just all the chars spewing out with no breaks, and no buffering. Weird!

Thanks!

I changed to release, but build it from Unity, so maybe it didn't override things. I also tried the C string quoting too - figured that would help.

I appreciate you taking a look - great technical support!