Digistump Forums
The DigiX => DigiX Support => Topic started by: rholt on July 08, 2014, 08:23:21 am
-
I have two Digix boards that I'm quite sure I've blown the i2C ports out of.
while programs like "Blink" are working, whenever I try to run a known good program that incorporates i2c, (even with all pins disconnected) just as the program finishes the compile, the COM ports disappear (from Device Manager on Windows) of both boards.
I have an UNO board that is working just fine with this setup.
So... i'd like to return the 2 boards for repair - i will pay for their repair.
thanks...
also... i just received a NEW (third) Digix board. oddly, the anti-static bag it was shipped in was NOT SEALED but rather it had scotch tape over the open end of the bag. While the lights come on when i hook it up, there is no COM port showing up under my Windows (win 8.1). i would like to exchange this for a new one.
Please let me know how to go about these returns and repair.
thanks,
Russ Holt.
-
I have two Digix boards that I'm quite sure I've blown the i2C ports out of.
while programs like "Blink" are working, whenever I try to run a known good program that incorporates i2c, (even with all pins disconnected) just as the program finishes the compile, the COM ports disappear (from Device Manager on Windows) of both boards.
That is impossible! The DigiX does not know, that you are compiling! The first possibility causing this, is when the DigiX restarts after the download of a program has finished.
Post one of those programs and tell us, which board setting (and which Arduino IDE revision) you are using.
-
gogol,
Obviously, "compile" was NOT the term that I should have used, and I apologize. I'm very new to all of this and don't yet have the hang of the terminology.
Attached is an example ino that works with my Arduino Mega 2560 board, but not (anymore) with my Digix board.
Usually, when I power up my Digix board, it many times comes attached to a different COM port, ie COM 4 or COM 5, but then when load the program, the COM 4 (or 5) will disappear from my Device Manager (in Windows) and reappear as COM 10 and the program will run.
But now, the Program loads and says at the end "Set boot flash true. CPU reset." but when i click on the Serial Monitor, I immediately get the "Board at COM5 (or 4) is not available." error message. The same thing happens with both Digix boards. (see attachment)
Russ
-
I forgot to add that I'm using the Arduino 1.5.6-r2 IDE with the DigiStump DigiX (standard) board.
-
I think, that your boards are not necessarily broken, when looking in your code.
When I load your code in one of my boards (original DUE and DigiX) they stuck as well.
Next point for checking is, that I just extended the Blink-Example with the acceleration library.
(I assume, that you are using: https://code.google.com/p/mma-7455-arduino-library/)
#include <Wire.h> //Include the Wire library
#include <MMA_7455.h> //Include the MMA_7455 library
int led = 13;
// Once the following line is enabled, the sketch hangs and no USB enumeration will take place
//MMA_7455 mySensor = MMA_7455(); //Make an instance of MMA_7455
void setup() {
pinMode(led, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
Here comes the point, where you need to dig deeper into the sketch, and why it is hanging!
The point is, that the board is first recognized, when the USB init code can be called. If that can't be called, you will see no device!
If your sketch does not behave like you thought, try to reduce it to a bare minimum.
-
gogol,
I see what you're saying, and, as i recall (because of your statements) , when I was first troubleshooting the program, I remembered that the code did not hang when I commented out the creation of the instance of "MMA_7455 mySensor = MMA_745"
I'll do some experimenting when I get home today - thanks for the suggestion.
Russ
-
gogol (and everyone)...
So, I'm home now - I hooked up my board to my new Gyro board which uses i2c and I have Data!
I will assume there is work to be done with the Accelerometer code.
Thank you VERY much for your direction in this!
But of course there's a new problem - and it is with the data I'm getting from the code from my Gyro L3G4200D.
My sketch is creating the x value, by reading 2 bytes at Register Addresses "0x29" and "0x28" then combining them:
x = ((xMSB << 8) | xLSB);
When I run the code on both the Arduino Mega2560, the BINARY readings are correct, and when I Serial.print in Decimal, the Mega shows the correct signed Int's (giving both positive & negative values), but the Digix shows unsigned giving VERY skewed values.
Russ
-
The int data type on ARM systems is 32-bits, while it is 16 bits on AVR systems. So what you want to do is use a 16-bit cast to short, which will sign extend the 16 bit item:
unsigned char low, high;
int combo;
high = get_high_byte ();
low = get_low_byte ();
combo = (short)((high << 8) | low);
-
MichaelMeissner,
Thanks so much - works like a charm! (I have so much to learn!)
I really appreciate the help on this forum.
Russ from Coral Springs, Fl.
-
MichaelMeissner,
Thanks so much - works like a charm! (I have so much to learn!)
I really appreciate the help on this forum.
Russ from Coral Springs, Fl.
Well in this case, it comes up fairly frequently as people migrate from AVR based Arduinos/Digisparks/etc. to ARM based systems. Three other compatibility things that bite people include:
- char without a signed or unsigned modifier, is unsigned on ARM systems, and signed on AVR systems;
- The AVR compiler makes double the same size and representation as the 32-bit float type, while under the ARM compiler, double is 64-bits, and float is 32-bits;
- The ARM does not need the PROGMEM decorations (in theory, the defaults in the Arm headers should allow code to work fine).
-
Don't forget in your enumeration:
- using libraries developed for AVR and never tested/adapted to ARM.
-
Don't forget in your enumeration:
- using libraries developed for AVR and never tested/adapted to ARM.
Yep, particularly libraries that access hardware directly. I was just listing the compiler specific gotchas that I knew about.
Another thing that I forgot to mention is AVR is stuck back on GCC 4.3.2, and ARM platforms tend to use 4.7 (and hopefully moving to at least 4.8, since 4.7 is now frozen), and the C++ language implementation has changed. However, I typically see complaints about code developed on ARM, and trying to be back ported to AVR.
Another compatibility issue is at the library issue. I hate having to have separate programs for Digispark/Trinket/Gemma from Arduino/Teensy, due to the former using TinyWireS.h/TinyWireM.h and the later using Wire.h. I seem to recall there are other 'Tiny' issues between ATtiny85 and other platforms.
-
back to an older subject, i'm afraid -
the MMA_7455.h library (i've downloaded the newer one)...
and while the small program i have runs on the Arduino Mega2560, when i start the download on the Digix board (after resetting the board to Digix) it has the effect of disabling the COM port. (see the 2 screenshots of the instance before i Upload the program and after i upload the program. on the 1st screenshot, i've commented out the creation of the instance of the "MMA_7455 mySensor = MMA_7455();" and the program runs on the Digix. but (see the 2nd screenshot) - when i uncomment out that line, it loads (or seems to load) and then drops the COM Port. disappears from my Device Manager.
why is it ok on the Mega, but not on the Digix? (i should start a new thread?)
Russ from Coral Springs
-
back to an older subject, i'm afraid -
the MMA_7455.h library (i've downloaded the newer one)...
and while the small program i have runs on the Arduino Mega2560, when i start the download on the Digix board (after resetting the board to Digix) it has the effect of disabling the COM port. (see the 2 screenshots of the instance before i Upload the program and after i upload the program. on the 1st screenshot, i've commented out the creation of the instance of the "MMA_7455 mySensor = MMA_7455();" and the program runs on the Digix. but (see the 2nd screenshot) - when i uncomment out that line, it loads (or seems to load) and then drops the COM Port. disappears from my Device Manager.
why is it ok on the Mega, but not on the Digix? (i should start a new thread?)
Russ from Coral Springs
The answer, simply, is that the library is not compatible with the Digix/SAM3X8E as it is currently written. I have no interest in this library, so I cannot invest the time to tell you what, exactly, needs to be changed. Until the library is modified for the Digix/SAM3X8E it will never work.
-
and while the small program i have runs on the Arduino Mega2560, when i start the download on the Digix board (after resetting the board to Digix) it has the effect of disabling the COM port.
First: It is NOT DISABLING the COM-port! It is never enabling the COM-port. Which makes a big difference. When the DigiX starts your program there is some initialization done. If that initialization hangs, because of malfunctioning libraries, the COM-port will never be enabled! This understanding is necessary, as there might be other errors, when a initialized COM port gets disabled during run-time of your sketch.
Second: That is, why I mentioned the use of libraries, which are never tested for the Arduino DUE / DigiX!
As the AVR family of microcontrollers is totally different from the ARM architecture, most libraries (which are not only on the abstract Arduino Layer) need adaption!
For that reason, there is the topmost sticky thread in the Arduino-DUE Forum (http://forum.arduino.cc/index.php?topic=144446.0), that one, talking about which libraries are tested and working!
You can start digging into that yourself, or ask the maintainer of that specific library!
-
kd7eir & gogol,
I get your point and they're well taken - I just figured that the newer library would have made itself compatible with all arduinos, including the DUE. I must learn to trust NO ONE!!1 :o.
I will now start looking into what general things have to be looked @ when converting Libs over from AVR to ARM. I'm not sure how much help i can be right now, but I'm sure willing to start learning.
thanks again for you comments on this.
gogol,
Thanks for clearing up the "disabling the COM port" issue. Whenever i click the Download button (and simultaneously watching the Windows Device Manager) I see that it's up, and the DL seems to go through 2 iterations. after the 1st iteration, the COM port will usually switch from the Bossa to the Digix port on Device Manager. Then, after the 2nd iteration, it disappears from Device Manager. I think what you're saying is that after the 1st iteration, the Digix connects to the (correct) COM port, but while running the 2nd iteration, because of software issues, is unable to connect to the COM port and therefore it is NOT SHOWN on Device Manager rather then BEING disabled. If that is so - thank you for the clarification.
Russ from Coral Springs, Fl.
-
I think I may have found at least a possible cause to my problem when reading through that "Digix Pinout Documentation" thread. In it MichaelMeissner mentions in his Jan 9, 2014 @ 10:45am post:
"In looking at photos of the Due, Mega, Leonardo, and DigiX, it answers a question I've had in looking at various library code. I've seen various library code that does I2C that uses the 2nd I2C port instead of the first i2C port. It looks like yet another case of the Arduino team changing their mind as new boards come up.
In the Uno R2, they used A4/A5 as the I2C pins. Then when the Uno R3 they come out with the new shield layout, and add 2 pins next to AREF for the I2C pins, and wire A4/A5 to use it.
Then the Mega comes out, and it has SDA/SCL relocated to pins 20/21, but I believe it still uses the 'common' I2C pins next to AREF."
If I have time @ work today, I'll look deeper into that MMA_7455 Library to see if THIS MIGHT BE WHY the program is working on my Mega board and not the Digix -> because it may be looking to run off the 2nd I2C ports which are at pins 70 & 71 up by AREF (?).
If I don't have time during work, I will check it out when i get home. I'll also keep looking.
Russ from Coral Springs, Fl.
-
Thanks for clearing up the "disabling the COM port" issue. Whenever i click the Download button (and simultaneously watching the Windows Device Manager) I see that it's up, and the DL seems to go through 2 iterations. after the 1st iteration, the COM port will usually switch from the Bossa to the Digix port on Device Manager. Then, after the 2nd iteration, it disappears from Device Manager. I think what you're saying is that after the 1st iteration, the Digix connects to the (correct) COM port, but while running the 2nd iteration, because of software issues, is unable to connect to the COM port and therefore it is NOT SHOWN on Device Manager rather then BEING disabled. If that is so - thank you for the clarification.
Yes, that is in short what is happening. You can read it in the Wiki in longer: http://digistump.com/wiki/digix/tutorials/programming
When a program is loaded and running on the DigiX, that program initializes the USB port. In case of the DigiX, that is done in some core board depended code, which is part of every program. It is not possible to upload code to the DigiX/DUE, when a standard program is running. Therefore the board needs first to be reset into BOSSA-mode, which makes programming possible. So you see normally three states: The state where the board identifies itself as DigiX/DUE and is running a program. Than it gets reset ino BOSSA-mode, the DigiX/Due COM-port disappears and the BOSSA-port appears. After the code is uploaded, the board gets a reset command again (after the NVRAM is configured to boot from flash) and that makes the program running again in DUE/DigiX mode.
When -and that is your case- the program hangs during initialization, the COM-port becomes not visible. You need to erase the program manually, which brings the board again in BOSSA-mode.
-
Thanks, gogol,
I'll be reading that link, today.
I'm also going to walk myself through the MMA_7455.h (accelerometer) Library, and the Wire.h Library, in order to begin my journey to find out why my program hangs when I try to create an instance of the MMA7455 in the program. I'm so not up to speed on this, but I have to tell ya, at the same time, I'm having a GREAT time going through the processes of learning. Certainly appreciate all the help I'm getting, and hope to pay it forward someday.
Russ from Coral Springs, Fl