Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nav6 Firmware build errors #9

Open
GoogleCodeExporter opened this issue Mar 14, 2015 · 6 comments
Open

nav6 Firmware build errors #9

GoogleCodeExporter opened this issue Mar 14, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
Following the build instructions at 
https://code.google.com/p/nav6/wiki/Customization fails.

What is the expected output? What do you see instead?
Compiling inv_mpu_dmp_motion_driver.c should succeed.  Instead I get

inv_mpu_dmp_motion_driver.c:254:1: error: unknown type name 'prog_uchar'
 const prog_uchar dmp_memory[DMP_CODE_SIZE] PROGMEM = {
 ^
Error compiling.

The PROGMEM library isn't part of a top-level #include, though it might be part 
of some other level.

What version of the product are you using? On what operating system?

I'm trying to compile unmodified code from a trunk I downloaded today.
Mac OS X 10.9 Arduino 1.5.8


Please provide any additional information below.

It is also worth a note that between steps 2 and 3 of the instructions you have 
to import the nav6 libraries to get as far as this.  Perhaps there is another 
procedural step needed.  I've installed Arduino on a fresh machine to minimize 
interactions with other projects.

See attached error log.

Original issue reported on code.google.com by [email protected] on 21 Jan 2015 at 10:01

Attachments:

@GoogleCodeExporter
Copy link
Author

This was tested on MacOSX.

The nav6 firmware compiles OK using Arduino IDE v. 1.0.6 on MacOSX.

However, the firmware does not compile OK using the Arduino IDE v. 1.5.8.  For 
now, please use the Arduino IDE 1.0.6 on Mac OSX to compile the nav6 firmware.

Also, please note that each nav6 comes with the nav6 firmware pre-installed.  
So it is only necessary to load the firmware if you intend to modify it.

Finally, if you are using the Arduino IDE to reload the firwmare, please note 
that you must manually press the nav6 reset button immediately after starting 
the download from the Arduino IDE.  This is because the ability for the Arduino 
IDE to reset the nav6 when downloading (which is accomplished via the DTR line 
on the RS-232 port) has been disabled.  The reason it was disabled is that on 
the CRio platform, the board would be sometimes reset when the serial port 
class is constructed, which causes operational problems.

Original comment by [email protected] on 21 Jan 2015 at 10:59

@GoogleCodeExporter
Copy link
Author

Acknowledged.  I am able to build with Arduino IDE 1.0.6 .  Perhaps the bug 
here is an Arduino IDE bug.

Yes, my interest in changing the firmware is related to a small change I want 
to experiment with in the protocol.

I thought cutting DTR or unsoldering a cap was needed to get this reset 
behavior.  I'm pleased to see it's become the default as it's a shame to lose 
that calubration time to a second reset.

Original comment by [email protected] on 22 Jan 2015 at 1:40

@GoogleCodeExporter
Copy link
Author

Apparently, it's a "feature"

https://github.com/arduino/Arduino/issues/2456

Just use uint16_t, newer toolchains dropped all PROGMEM-specific types (see 
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html#ga93ec00229
866bf6a125384ad08cefa73)

Original comment by [email protected] on 22 Jan 2015 at 1:48

@GoogleCodeExporter
Copy link
Author

Could you provide a little guidance on the "manually press the nav6 reset 
button immediately after starting the download from the Arduino IDE" comment.  
When I click upload, the Arduino IDE recompiles the program and then uploads 
it.  If I press the reset button when I click the upload, the IDE is still 
compiling when the nav6 has started transmitting.  I've tried dozens of times, 
and sometimes I can get an "avrdude: Send" message, but no successful uploads.  
I always get an "stk500-getsync: not in sync." error.  I also note that the 
Arduino Uno uploader defaults to 115600 rather than the 57600 you use in normal 
communications.  Here is an example failure.

Binary sketch size: 30,088 bytes (of a 32,256 byte maximum)
/Users/saundr1/Atholton/Kauai 
Nav6/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude 
-C/Users/saundr1/Atholton/Kauai 
Nav6/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v 
-v -v -v -patmega328p -carduino -P/dev/tty.usbserial -b115200 -D 
-Uflash:w:/var/folders/vf/_hz_ggg93vb0jbxz05wyl0d1ds_3x9/T/build3035254025365714
288.tmp/nav6.cpp.hex:i

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

         System wide configuration file is "/Users/saundr1/Atholton/Kauai Nav6/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/saundr1/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/tty.usbserial
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [e6]
avrdude: stk500_getsync(): not in sync: resp=0xe6

Original comment by [email protected] on 5 Feb 2015 at 8:57

@GoogleCodeExporter
Copy link
Author

The issue here is often one of timing.  When the upload button is pushed, a 
build will occur, which can take a variable amount of time.  The releasing of 
the nav6 reset button should occur immediately after the first initiation of 
the avrdude (as soon as the first "Send: 0" statement occurs, as shown in your 
display).

The Baud Rate should not be an issue, since the nav6 uses the default Arduino 
Uno bootloader.  Do make sure that the "Tools->Board" type is set to "Arduino 
Uno".

Original comment by [email protected] on 5 Feb 2015 at 10:19

@GoogleCodeExporter
Copy link
Author

As a note, after releasing the reset button, the ATMEGA328P will begin 
executing the boot code within less than 10ms.  This boot code will only be 
active for about 2 seconds, so that's the window of time you have to work with.

Original comment by [email protected] on 5 Feb 2015 at 11:19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant