Openlog with MSP430


I've design a custom board with the main mcu being a msp430. I also have an openlog on the board and I am having trouble getting it into command mode. After looking at the arduino examples, I see that Serial.write(26) is written three times to enter command mode. So the msp430 is sending commands to the openlog via UART and so far I've been able to store data when the openlog is in read mode but I haven't been able to get it into command mode and I suspect its because the msp430 isn't matching the arduino protocol exactly.

My question is, is the 26 in decimal form (which is 0x1a) or is that already in ascii form (which is 0x3236). I haven't been able to find a sure answer on that one yet.

So far it is not working as I've not been able to detect the '>' character in the receive buffer after I send the command prompt three times. I scoped the RX lines on a arduino and found it sends its data LSB first and and LF in between each character.

Any tips would be helpfu!

Serial.write(26) is sending the value 26 and not the ASCII values of '2' & '6'.

Serial protocol is serial protocol and should be sending data in the same bit order on any UART device. You might encounter a situation where the signal is inverted but that has nothing to do with bit order.

Serial.write(x) will only send the value x and not put an LF on the end of it so I don't know why your seeing the LF.

Do you have the correct baud rate selected?

What model of MSP430 are you using?

Does the Energia IDE & core files correctly emulate/compile the Arduino commands?

So by value 26 you mean the decimal value 26, which is hex 0x1a?

And sorry, I was seeing the LF characters on serial.print. I am certain of this. For example, Serial.print(“read”) showed 0 (01001110) 10 (10100110) 10 for ‘r’ and ‘e’ and so on.

I am using a baud rate of 9600 for the msp430 and the openlog is set to the same. I am using the msp4302274 and I am not using energia. I am using CCS and writing in C.

I find it odd that I am able to send data to the openlog, have the openlog store that data, but I haven’t been able to receive anything from the openlog. Not even the initial ‘12<’ command. I read elsewhere that the msp430 UART line is effectively ground when set to zero and that this condition on an openlog start up will perform a factory reset. Here is the link OpenLog and MSP430 UART - SparkFun Electronics

I am also noticing some strange patterns with the openlog, where it doesn’t save the data onto the SD perfectly. If I want to send it 3 zeros, I noticed that I first have to send about 14 or 15 dummy values, then send the 3 zeros and those will be recorded. Almost like its dropping the first few values received. Also, sometimes the data is written in chinese, and other times it works the way it should.

I can send the equivalent of: “read”, “log001.txt”, “/r”, which should be the read command (once in command mode) and I see this exact data written to the card. This is another hint that leads me to believe I am not entering command mode because I don’t think that data would be writing to the card if it indeed was in command mode.

For an update:

I determined that I had a hardware issue with the uart lines, but I fixed it.

Now when I run the openlog, it prints several ones and twos and the occasional < character, like so:
11111111111111222222222222<, etc.

Why would it be acting like this? Could it be getting reset?

Still can’t configure it to go into command mode even though I am sending the exact same binary data as serial.write(26) does (three times).

Are you certain the baud rate, start/stop bits and data bit count are correct AND the logic/voltage levels of the serial data are as expected.

I figured out my problem. The first thing I do is cycle the power on the openlog. Next I give a reasonable delay before I sent the command mode commands, then I send said command 100 times. Not sure why I have to send it this many times, but it works.

Sending the command 100 times means there is still something very wrong with the setup. Does the Openlog correctly record your serial data or is it corrupted or with big holes?

How do you mean there is something wrong? I agree its odd that I must send it 100 times. Actually I've noticed that sometimes it will work sending it 1 time, if I am in debug mode, but if I plug in the battery without debug mode it doesn't work.

The openlog does store the serial data correctly. Its not corrupted and there are no holes in the data.