UDOO Hangs, Stock DUE doesn't. (DHT22)

Hi,

I'm frustratingly trying to start using my UDOO Arduino. It doesn't perform like my stock Arduino DUE; which is obviously trying my patience and I would greatly appreciate some advice.
I'm running the latest ubuntu image and the Arduino 0154 it comes with.

MINOR ISSUE
1. It seems i have to use a jumper J16 to reset the DUE every time i program it, otherwise the serial monitor doesn't work. Is this normal for UDOO?

MAJOR PROBLEM
2. Using a DUE compatible sensor library from http://playground.arduino.cc/Main/DHTLib.
The Stock DUE can run it perfectly, no hassles, reads my DHT22 sensor... no need for resets. It just works.
The UDOO on the other hand, just hangs the second it queries the sensor......
Now everything is identical, both hooked to the 3.3V/GND for power, both hooked to pin 6.

Somewhere in the function below, the UDOO fails or something.
NOTE that humidity and temperature variables are doubles.

THe function call that does not return

Code:

int chk = DHT.read22(DHT22_PIN); 

The Function in the library DHT

Code:

// return values:
// DHTLIB_OK
// DHTLIB_ERROR_CHECKSUM
// DHTLIB_ERROR_TIMEOUT
int dht::read22(uint8_t pin)
{
	// READ VALUES
	int rv = read(pin);
	if (rv != DHTLIB_OK)
    {
		humidity    = DHTLIB_INVALID_VALUE;  // invalid value, or is NaN prefered?
		temperature = DHTLIB_INVALID_VALUE;  // invalid value
		return rv; // propagate error value
	}

	// CONVERT AND STORE
	humidity = word(bits[0], bits[1]) * 0.1;

	if (bits[2] & 0x80) // negative temperature
	{
		temperature = -0.1 * word(bits[2] & 0x7F, bits[3]);
	}
	else
	{
		temperature = 0.1 * word(bits[2], bits[3]);
	}

	// TEST CHECKSUM
	uint8_t sum = bits[0] + bits[1] + bits[2] + bits[3];
	if (bits[4] != sum) return DHTLIB_ERROR_CHECKSUM;

	return DHTLIB_OK;
}

 

Are you programming the Arduino from your PC or the Ubuntu GUI?
I had issues programming with the Ubuntu GUI. I had better success programming from my PC.

 

Upon closer inspection, the first line to fail is

Code:

humidity = word(bits[0], bits[1]) * 0.1;

Its the binary shifting I believe; but no idea how I would fix it...

@lancetoups
Thanks for the reply
I was using the Ubuntu GUI. I appreciate the work around but I got the UDOO since its all in one.... and making changes via Ubuntu is a big chunk of that.
I'll do the work around if needed, but why the hell would the UDOO have a difference in the libraries

 

that is strange, given that both boards use the same Microcontroller chip for the Arduino side... I could see it if they were different chips that could handle the bits differently, but they're not.

As somebody else suggested (just to try it out) try loading your code via another PC into the Udoo's Arduino side and see if it changes things at all. I guess it could be possible that the compiler from the Udoo's ubuntu side is messing something up when compiling the code....

Conversely, hook your Due up to the Udoo and program it via the Udoo's Ubuntu side and see if it still behaves correctly or if it has the same problem you see with the Udoo's Due side?

Wish I could help more... Let us know what you find out.

 

How many pages large is the sketch when it uploads? I am almost certain this is a common issue. I have had many different things cause the Udoo's Due to hang, and the only common thing to them is the program space size being over about 100 pages.

A common fix for these kinds of errors seems to be to compile and upload from an external computer after removing one of the jumpers. I think this works because the different version of the IDE produces smaller binaries when it compiles.

 

I am having the same issue using an udoo quad with the debian jesse armhf/GPU acceleration distro. I've also had the SAME issue when programming from 1.54 or 1.55 from my macintosh. I also have to do J22 to bow away the flash on the DUE to program it as well.

 

I seem to have developed a very strange fix for this. I'll outline the exact steps I took to get around the issues and report back if I come up with a more precise fix.

First, the issue as I see it is that the Due completely freezes up when certain sketches are uploaded. This happens on anything with atof() in it for me, so I thought it might have to do with floats. However, it also froze when I tested an i2c led matrix. So I suspect it has to do with sketch sizes and maybe the upload duration. If someone else could confirm that atof does not work in their sketches that would be helpful to me. Here is a minimal version of code that will cause crashes:

Code:

void setup() { Serial.begin(9600); }
void loop() { Serial.println( atof("12.345") ); }

Now when I say freeze, I mean that it stops doing serial output and will not blink LEDs hooked up to GPIO. It also cannot be reset using the jumper. When the sketch is first uploaded, an LED will blink for a very short duration before it stops. Shorting the reset jumper will not cause it to blink again.

My "fix":

1. Setup the Due to be programmed by external computer by removing the jumper. The remainder of the steps are from the external computer.
2. Download the official Arduino nightly (my system is a Linux 64 bit)
3. download the bossac patch
4. rename the old bossac binary to something like "bossac.default"
5. move the udoo bossac binary to the /hardware/tools/ folder
6. upload a sketch that crashes (see above code)
7. (without needing to close IDE) rename current bossac binary to "bossac.udoo" and rename "bossac.default" to "bossac"
8. amazingly, this second upload will actually upload a fully functional version of the sketch

Another fix:
I think this issue may have to do with a bug in an AMD USB controller referred to here: https://github.com/UDOOboard/BOSSA. The computer that had the issue has a AMD SB710 south bridge / USB controller with a AMD 785G north bridge. I installed the Arduino 1.5 IDE on a different (and windows 7) machine, the http://www.silabs.com/products/mcu/pages/usbtouartbridgevcpdrivers.aspxUART driver, and the BOSSAC patch. It worked without any of the above fuss. It also has an AMD USB controller, but a much newer one (AMD A55). I do not quite believe that the AMD USB host controller is source of the core problem because it does not quite explain the issue on why the sketches cannot be compiled and uploaded from the UDOO, which does not have a USB controller between the two processors, much less one by AMD. Perhaps I experienced two separate issues?

 

I seem to have a similar issue. When I upload some complex programs, the Udoo hangs. I have done several tests and it appears that any program with a size > 120 pages causes the problem.

The same issue happens when I program from the Udoo and from my Mac (running maverick).

I have tried the code supplied by EchoWarp with atof, it does run properly for me.

The workaround I found is to use the alternative programming method described in the Udoo manual, without using the modified bossac, which is basically:
- stop the Udoo boot sequence using the serial debug
- erase the Arduino using the jumper J22
- reset the Arduino using the jumper J16
- upload the program with the unpatched Arduino IDE


It appears to me that there is something wrong with the modified bossac. I’ve done a few more tests and get some inconsistent results, for example:
- upload sketch 1 -> works
- upload sketch 2 -> hangs
- upload sketch 1 again -> hangs
- restart the Udoo -> still hangs
- upload sketch 1 -> works