SparkFun Forums 

Where electronics enthusiasts find answers.

Your source for all things Atmel.
By potoole
#95288
I tried to change the baud rate of my OpenLog while it was connected to Hyperterminal. A message appeared stating: "moving to 'new baud rate" and just stuck there. I disconnected it(probably shouldn't have) from hyperterm. then reconnected. I get the '12<' alright, but if I try to ctrl-z, or hit any button the terminal fills up with endless '12<', non stop..

I have tried:
1)if you get OpenLog stuck into an unknown baud rate, there is a safety mechanism built-in. Tie the RX pin to ground and power up OpenLog. You should see the LEDs blink back and forth for 2 seconds, then blink in unison. Now power down OpenLog and remove the RX/GND jumper. OpenLog is now reset to 9600bps.
It did just as stated, no help[

2)reset manually, get a small bit of wire and find the reset connection on the 4 hole SPI interface – it is the square connection hole near the “O” where it says OpenLog on the silkscreen. Short that pin to a ground – the connector for the 6 pin at the opposite corner is ground, as is the metal case for the micro SD card (which is directly below the reset hole). The bootloader is only active for a fraction of a second so you need to hit enter and do the reset at the same time. You can also disconnect one of the power lines (e.g. GND) and reconnect it just as you press Enter to run the avrdude command.
Done so, didn't help.


3)Redownloading 'Openlog files', reflashing main.hex - nothing helped.

Anybody have any ideas of how to get it out of that endless loop?

I had it working just fine while connected to arduino pro, using the following arduino sketch. (I should have left well enough alone) :cry: :oops: :roll:
Reads incoming electronic pulses on arduino dpin3, saves data to SD card as pulses/sec and the corresponding seconds of time.
Code: Select all
unsigned long tme = 0;  
unsigned long ret = 0;
int length = 6;  //not used
volatile int y = 0;
//int seqn = 8123; //used for test purposes 
int ylast = 0;
int ynow = 0;

void setup() {
  Serial.begin(9600);
  attachInterrupt(1, pulsin , FALLING);  //using arduino pin3 
  
}

void loop() {
  while (millis() <= 300000){   //  Allows data collection for 5 minutes, can be changed
  tme = millis();
  if (tme - ret >= 1000){ //results in 1-sec readings
    int secs = tme/1000;
    Serial.print ("secs = ");
    Serial.print (secs);
      Serial.print("\t");              // prints a tab

    ynow = (y - ylast);  // y = sum of pulses from interrupt/sec
    ylast = y;

    ret = tme;
        Serial.print ("ynow = ");
      Serial.println (ynow);  //= # of pulses/second(just read)
  }
}}

void pulsin(){  //interrupt on 3
  y = (y + 1);  //reads each incoming pulse, adds to total each second
}



/*Connect the following pins:
 OpenLog VCC to Arduino 5V
 OpenLog GND to Arduino Gnd
 OpenLog TXO to Arduino dPin 0(RX)
 OpenLog RXI to Arduino DPin 1(TX)
 OpenLog grn to Arduino Serial pin RST(GRN)*/
By bkuhns
#96114
I just noticed we have the EXACT same problem.... very strange. Everything I've thrown at it hasn't fixed it. Hopefully someone else has some ideas or our combined tinkering can find a solution. I'll keep you posted if I find something!

In case something I mentioned in my post will help trigger a light bulb for someone: viewtopic.php?f=8&t=20692&p=96115
By bkuhns
#96118
I noticed between our experiences that we both were attempting to get into command mode when this happened. When I have a chance later tonight or maybe tomorrow, I'm going to grab the firmware code and take a look at how it handles the ctrl+z switch to command mode. Maybe it's saving a bad value in EEPROM which is now causing OpenLog to loop the 12< over and over. Purely speculation, but it's an idea I'd like to dig into. I'll update my findings later.
By bkuhns
#96250
I've found a few issues in the source code that I've submitted on GitHub.

http://github.com/nseidle/OpenLog/issues/#issue/15

I think I see a problem with my own changes though. It's because I was following what was done originally in the code. I have no basis for this, but my changes point out a bug in the code when setting the log file number for the next power-up of OpenLog. There's code to ensure the new number wraps properly from 255 to 0, but only when first entering the newlog() function. After it does that check, it then goes and makes sure that log file number is available on the card, if not it increments the log number but never validates this new number. I don't have a way to debug this at the moment, but perhaps incrementing without explicitly wrapping the value [number = (number + 1) % 255] is causing OpenLog to crash at runtime and reset.

This theory would explain the looping "12<" since the code for outputting "12<" comes before the newlog() function is called. I really need to find a way to test this out...
By bkuhns
#96265
Did you check the contents of your microSD card? I noticed mine filled up with log files from 0 to 255 and I was curious if you had this happen as well?
By potoole
#96317
bkuhns
Post subject: Re: Help, OpenLog is stuck in endless loop.Posted: Mon Mar 15, 2010 9:33 am

Posts: 9 Did you check the contents of your microSD card? I noticed mine filled up with log files from 0 to 255 and I was curious if you had this happen as well?
Nothing showed up on the card. I don't know what to do with the thing. I was hoping there was some way of salvaging the device. Perhaps, uploading an arduino sketch to it, and still use it as a data logger, but I'm not sure of how to enter data to it. I don't know if the pins that are readily available can be used for data entry.

I tried to download the OpenLog hex file by the use of a parallel programmer, but it made no difference.

PO'T
By bkuhns
#96318
potoole wrote:I tried to download the OpenLog hex file by the use of a parallel programmer, but it made no difference.
Yeah, I'm pretty sure based on that alone, that this is a problem with the code writing a bad value to EEPROM. That's why I keep focusing on the file number. With the combination of my log 0-255 issue (which is the limit of file numbers for OpenLog) and uploading the HEX doesn't seem to work, it seems to be pointing directly at a problem with EEPROM and how the file number value is handled.

Perhaps OpenLog needs a more "hardcore" reset than just baud rate. Something that will reset everything, including EEPROM, to "factory" defaults. Once I figure out how to get firmware updates onto the chip, I'm going to start hacking away at the code and see what I can come up with, hopefully if I can fix my problem, you can duplicate it and get your's going as well.

To jump start my progress, how did you get that HEX file uploaded? Did you follow a tutorial?
User avatar
By sparky
#96905
Hi,

Thanks for your help and patience on this problem. There's two things going on:

1) In v1.1 there was certainly the possibility to have an SD card fill up with 255 logs. Once this happened, open log would loop endlessly looking for an open spot to create a log. The solution was to delete any zero byte logs. Not great.

ringp has helped extend the new log function. We now support in v1.2 65533 potential logs. And I added error checking so that if you do find yourself sitting on log # 65533, it will error out to the command prompt gracefully. bkuhns - hopefully this will fix your issue.

2) potoole - What baud rate where you trying to go to?
I tried to change the baud rate of my OpenLog while it was connected to Hyperterminal. A message appeared stating: "moving to 'new baud rate" and just stuck there. I disconnected it(probably shouldn't have) from hyperterm. then reconnected. I get the '12<' alright, but if I try to ctrl-z, or hit any button the terminal fills up with endless '12<', non stop..
This is actually correct. OpenLog will hang, waiting for a power cycle. This is specified in the command set here:
http://wiki.github.com/nseidle/OpenLog/command-set
The baud rate selection is immediate and OpenLog requires a power cycle for the settings to take effect. The baud rate is stored to EEPROM and is loaded every time OpenLog powers up.
So potoole,that's not your problem. You did everything right.
2)reset manually, get a small bit of wire and find the reset connection on the 4 hole SPI interface – it is the square connection hole near the “O” where it says OpenLog on the silkscreen. Short that pin to a ground – the connector for the 6 pin at the opposite corner is ground, as is the metal
Nice detective work, but not needed. You can reset OpenLog from the pin labeled 'GRN'. This is connected to reset through a capacitor. Just touch this pin to ground and the unit will go into reset (as the cap discharges) and then return to normal operation (as cap recharges). See datasheet section 'GRN':
http://wiki.github.com/nseidle/OpenLog/datasheet

I don't have a good setup to test your Arduino code atm. Please keep hacking at it and let me know if you continue to have problems.

Known OpenLog issues are best addressed on the GitHub page:
http://github.com/nseidle/OpenLog/issues

Cheers,
-Nathan
By bkuhns
#96910
This certainly fixed my problems, OpenLog is running like a champ once again, thanks Nate! Since potoole seems able to compile a hex and load it to OpenLog, I would suggest blindly loading the latest version of the firmware and see if that by chance fixes the problem. If not, then I wish the best of luck to you...
By potoole
#97057
1) In v1.1 there was certainly the possibility to have an SD card fill up with 255 logs. Once this happened, open log would loop endlessly looking for an open spot to create a log. The solution was to delete any zero byte logs. Not great.
Wouldn't a new card fixthis problem?
ringp has helped extend the new log function. We now support in v1.2 65533 potential logs. And I added error checking so that if you do find yourself sitting on log # 65533, it will error out to the command prompt gracefully. bkuhns - hopefully this will fix your issue.

What do you mean, " We now support in v1.2 65533 potential logs" ? How will this help me, is it something that I can download?

2) potoole - What baud rate where you trying to go to?
I was trying to move it to baud rate of 57600. It was working fine at 9600 before I attempted that. Getting my OpenLog to work would be great. However, I was trying to add a time stamp, by the use of a 1307 RTC, and the time stamp would not enter in the proper location for me; it was not entering in the time I wanted it to, which was right at the beginning of data collection. Time stamp was getting mixed with data, so I thought changing baud rate would help. And that's where the trouble all started.(PO'T)
By bkuhns
#97061
potoole wrote: Wouldn't a new card fixthis problem?
I had the same thought. I tried formatting my card and swapping out for a new one and that didn't solve the problem. Having 255 logs seems to trigger the problem, but it seems to get stuck as soon as the case is reached and it doesn't matter anymore if you clear the card.
potoole wrote:
What do you mean, " We now support in v1.2 65533 potential logs" ? How will this help me, is it something that I can download?
The new firmware now supports log files up to LOG65533.txt, the old limit used to be LOG255.txt. You can download the latest source code, compile the HEX, and transfer it to OpenLog. That's how I fixed the problem.
By bkuhns
#97062
Although it's not hard to compile the hex, if you're not able to do that, let me know and I can send you the latest hex I built. I believe Nate has pushed some newer commits for v1.3 already (I have v1.2 built), but it's the build that fixed my OpenLog, so maybe it'll work for you. Let me know and I'll send it your way.
By potoole
#97074
bkuhns
Post subject: Re: Help, OpenLog is stuck in endless loop.Posted: Fri Mar 26, 2010 8:33 am

Although it's not hard to compile the hex, if you're not able to do that, let me know and I can send you the latest hex I built. I believe Nate has pushed some newer commits for v1.3 already (I have v1.2 built), but it's the build that fixed my OpenLog, so maybe it'll work for you. Let me know and I'll send it your way.

Yes, please send your new hex file my way. I'm not particularily adept at programming; I'd probably screw things up. :D

Thank you,
Patrick