Show Posts
Pages: [1]
1  Using Arduino / Interfacing w/ Software on the Computer / Re: Arduino Mega ADK Serial.print stale data issue on: October 18, 2012, 11:30:18 pm
The header is in the receiver code (so I can pipe it into a file just like that), and should signify the point where my PC is ready to receive the data.

The code on the Mega ADK is this one: https://github.com/imrehg/sketchbook/blob/master/Thermocouple5/Thermocouple5.ino

The receiver code is something like this in Python (with just the relevant parts shown):
Code:
dev = serial.Serial('/dev/ttyACM0', baud, timeout=1)
print "#HotJunction(C),ColdJunction(C)"
while True:
    print dev.readline()

I got around the problem a bit by throwing away the first 50ms data or so:
Code:
dev = serial.Serial('/dev/ttyACM0', baud, timeout=1)
delay = 0.05    # seconds
finish = time.time() + delay
while time.time() < finish:
    dev.readline()   # just reads but not prints
print "#HotJunction(C),ColdJunction(C)"
while True:
    print dev.readline()
In this case the buffer is received but not printed first, then later started to print the real (new) data.
2  Using Arduino / Interfacing w/ Software on the Computer / Arduino Mega ADK Serial.print stale data issue on: October 05, 2012, 03:25:35 am
Hi!

I was using a sketch that sends some sensor data over Serial to the computer, and had a python script to read it. It was running on a Diecimila-equivalent board. Now I have an Arduino Mega ADK, and run the sketch on that one. The problem I have, that first when read the serial on the computer, all I receive is a lot of stale buffer, then the board resets, then starts to read correctly.

To illustrate it, one example output reading the data received in on the computer side:

Code:
#HotJunction(C),ColdJunction(C)
31.25,0.69,9046
31.25,30.69,9548
31.25,30.69,10050
31.25,30.69,10553
31.25,30.69,11056
31.25,30.69,11558
31.00,30.69,12061
25,30.69,9046
31.25,30.69,9548
31.25,30.69,10050
31.25,30.69,10553
31.25,30.69,11056
31.25,30.69,11558
31.00,30.69,12061
0.00,0.00,0
30.25,30.25,501
30.25,30.31,1004
30.50,30.37,1506
30.50,30.44,2009

The first line is the header, printed after I connected to the board, but haven't read anything yet. Every line then is 3 comma-separated values: sensor reading, another sensor reading, finally a timestep in milliseconds since bootup. E.g the data line 31.25,30.69,9548 would be Sensor1=31.25, Sensor2=30.69, timestamp=9.548s since bootup.

Looking at the data, what I actually received:
  • 7 lines of stale data (lines 1-7)
  • A broken repeat of that stale data (lines 8-14)
  • Correct data after reboot (lines 15 up)
The amount of stale data is different run by run.

Where does this behaviour come from? I feel it's some buffering issue. Is there a way to avoid it? I guess it's a Mega ADK issue, because with the old board I haven't seen this. Might have to do something with the fact that there are so many serial lines on that board, and I guess the firmware control is different?

What I do now, is that I throw away whatver I read in the first 10ms of starting the computer-side script. It fixes things in a hackish way, but I'd love to understand what is actually going on there, and have a better way to do that.
3  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 05, 2012, 01:53:58 am
Try halving the baud rate in boards.txt and restarting the IDE.

It has the same result.
4  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 10:56:22 pm
I wouldn't be too worried about non-implemented bits reading back with 1 set. That does happen. According to the fuse calculator:

http://www.engbedded.com/fusecalc

both settings of the extended byte mean the same thing (the boot size).

Quote
Any other pointers what else to try?

I am wondering about the clock rate. Is this board running at 16 MHz? Also have you got the correct board selected in the Board menu? (Yes, I know it is a beginner question, but that is what I would be checking).

Also can you turn on verbose uploading information, and copy and paste the output you get when trying to upload a new sketch? Thanks.

It's 8Mhz. Yeah, I keep checking the settings in the boards menu as well to be sure. Since I burned the the Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega168 firmware, I keep choosing that one.

The output is this:

Code:
hardware/tools/avrdude -C/home/lab/Greg/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega168 -carduino -P/dev/ttyUSB0 -b19200 -D -Uflash:w:/tmp/build7496679973925227559.tmp/Blink.cpp:i

avrdude: Version 5.11, compiled on Sep  9 2011 at 16:00:41
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/home/lab/Greg/arduino/hardware/tools/avrdude.conf"
         User configuration file is "/home/lab/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : arduino
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.
5  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 05:06:42 am
The flashing works, verifies. Noticed that after flashing, the reported Extended Byte and Lock Bits are not the same in the detection code as set here. Is that normal behaviour?

What are they, then?

Flashing this:

Code:
{ { 0x1E, 0x94, 0x06 }, "ATmega168V",  16 * kb,       256,
        ATmegaBOOT_168_atmega328_pro_8MHz_hex,   // loader image
        0x3E00,               // start address
        sizeof ATmegaBOOT_168_atmega328_pro_8MHz_hex,
        128,          // page size (for committing)
        0xC6,         // fuse low byte: external full-swing crystal
        0xDD,         // fuse high byte: SPI enable, brown-out detection at 2.7V
        0x04,         // fuse extended byte: boot into bootloader, 512 byte bootloader
        0x2F },       // lock bits: SPM is not allowed to write to the Boot Loader section.

i get

Code:
LFuse = 0xC6
HFuse = 0xDD
EFuse = 0xFC
Lock byte = 0xEF

As another try, if I flash 0x0F for lock byte (as in the boards.txt), i get 0xCF as lock byte in the verification part.

From the fuse checker site it seems to me that 0x00 or 0x04 (the code and in boards.txt) are not really valid values for the Extended Fuse? E.g. 0xFF is a valid value, and that indeed flashes as such.

Hm.... Any clue in this?
6  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 03:59:00 am
- the fuse values are quite different from what I used before, the settings I got from this blog post.

Conceivably what happened was you interrupted the fuse writing at a bad moment. Also what that blog says (the parts I can understand) relate to what the fuse settings are changed to when you upload a bootloader, not when you upload a sketch.

I found some supplementary material from the magazine where I got this Japanimo board. They have an instructional pdf, where they basically say it is an Arduino Pro Mini (3.3V,8MHz)w/ATmega168.

Thus, looking at your code, I tried to flash with these settings:
Code:
  { { 0x1E, 0x94, 0x06 }, "ATmega168V",  16 * kb,       256,
        ATmegaBOOT_168_atmega328_pro_8MHz_hex,   // loader image
        0x3E00,               // start address
        sizeof ATmegaBOOT_168_atmega328_pro_8MHz_hex,
        128,          // page size (for committing)
        0xC6,         // fuse low byte: external full-swing crystal
        0xDD,         // fuse high byte: SPI enable, brown-out detection at 2.7V
        0x04,         // fuse extended byte: boot into bootloader, 512 byte bootloader
        0x2F },       // lock bits: SPM is not allowed to write to the Boot Loader section.

The low byte and high byte are copied from the boards.txt appropriate for that Arduino Pro Mini. The extended byte and lock bits are from the ATmega168PA settings of your code. The  start address is also copied, I have no idea where I could get the correct value.

The flashing works, verifies. Noticed that after flashing, the reported Extended Byte and Lock Bits are not the same in the detection code as set here. Is that normal behaviour?

After flashing, still nothing happens. Meaning, connecting the board to the PC the USB shows up, but no communication, not able to flash a new sketch. The loopback test works just fine.

Any other pointers what else to try?
7  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 01:39:14 am
The chip detector does not erase or change anything.

Yeah, of course, the chip detector just reads. I meant that the original problem of interrupted upload or something that I did before hand, messed up the bootloader.

I would not expect the bootloader to start with zeroes. And if the sketch is all 0xFF that looks like an erased program.

So should I try to reflash the bootloader (probably with your Atmega Board Programmer sketch) and see what happens?
8  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 12:50:02 am
Hi, finally got the Chip Detector sketch working. The chip on Japanimo is ATmega168V-10AU, added the signature to the sketch such as:

Code:
{ { 0x1E, 0x94, 0x06 }, "ATmega168V", 16 * kb,       256 },

The 16kb I know, the 256 bootloader size I just guessed based on the rest of the chips. The output of the detection is the following:

Code:
Atmega chip detector.
Entered programming mode OK.
Signature = 1E 94 06
Processor = ATmega168V
Flash memory size = 16384
LFuse = D2
HFuse = DE
EFuse = F8
Lock byte = FF
Clock calibration = B3
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 256 bytes starting at 3F00

Bootloader:

3F00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F80: 57 00 E8 95 00 91 57 00 01 70 01 30 D9 F3 01 E1
3F90: 00 93 57 00 E8 95 32 96 02 97 09 F0 C7 CF 10 30
3FA0: 11 F0 02 96 E5 CF 11 24 5C CF F8 94 FF CF 80 00
3FB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FF0: FF FF FF FF FF FF FF FF FF FF FF FF 07 04 06 B3

MD5 sum of bootloader = C5 0A 34 A2 77 92 2E D2 70 BF 65 70 2B 7C 3F 4F

First 256 bytes of program memory:

0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Some observations:
- there was uploaded sketch on this board before, does it mean that it got erased?
- the bootloader area starts with a bunch of 00s, is that normal? Or does that show that there's a problem?
- the fuse values are quite different from what I used before, the settings I got from this blog post.

Any recommendation to get this board working again? smiley
9  Using Arduino / General Electronics / Re: decoupling capacitor size on: October 03, 2012, 06:13:39 am
Quote
so I'll just try some bigger caps than so far.

It is not terribly critical. I usually use whatever I have and I tend to stay small. But starting with what the datasheet suggests helps. And for highspeed circuits, starting with a ceramic disc (monolithic or otherwise) helps as well. I usually avoid tantalum as they tend to fail short. 10nf - 110nf is fairly common.

Tantalum are rubbish for decoupling. So are most electrolytics.

Here's Atmel's advice on decoupling capacitors: http://www.atmel.com/Images/doc0484.pdf


Thanks a lot, this is very useful in general!
10  Using Arduino / General Electronics / Re: decoupling capacitor size on: October 03, 2012, 05:19:54 am
Thanks, it pretty much confirms my understanding. In this particular case I was working on the frequency response is not an issue, so I'll just try some bigger caps than so far.

Cheers!
11  Using Arduino / General Electronics / decoupling capacitor size on: October 02, 2012, 09:28:13 pm
Hi!

I'm making a project with a MAX31855 thermocouple amplifier chip. It has to have decoupling capacitors on the power lines, and also on the input lines. It is a very sensitive chip, and I found I have to increase and increase the decoupling capacitor to have a better behaviour. The spec sheet recommends 10nF, but I found even 1uF has some noise spikes every now and then.

This got me thinking, is there a "too high" value of decoupling capacitor, if my time scale is not too small (0.1-1s) ? Is there any reason why people recommend certain size of decoupling capacitors for power lines or signal lines? How could I think about these in general?
12  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 01, 2012, 04:42:14 am
Thanks, I'll check it out and get back with the results.
13  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 01, 2012, 01:53:05 am
Could that interrupted upload result in bricking or killing the board? Or the bootloader got damaged somehow? How could I test these things, or is there a way to fix it?

It should not do that (get killed). Do you have another board? (you could test the first with the second)

Yes, I have another board, how could I test the functionality of this one?
14  Using Arduino / Installation & Troubleshooting / Interrupted sketch upload results in bricking? on: September 28, 2012, 08:08:51 am
Hi,

I have a Japanino board (basically a clone of the standard board with ATMega168V), which was working fine so far. Today I was uploading a sketch, and by accident during the upload I clicked the upload button again. The upload failed, and since then the board is unusable. If I try to upload another thing, it just times out with
Code:
avrdude: stk500_recv(): programmer is not responding
and upon turning the board on, no reaction to the reset button, nor does the L LED light up (which would mean there's a functional bootloader, as much as I know).

Could that interrupted upload result in bricking or killing the board? Or the bootloader got damaged somehow? How could I test these things, or is there a way to fix it?
Pages: [1]