Raven Source Code - When?

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it's the end of April now.

Anyone heard when the Raven source code will be released?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i hope so

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In case you missed it, the source code and documentation for the firmware is now available on the ATAVRRZRAVEN 2.4 GHz Evaluation and Starter Kit product page.

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did miss it -- thanks for the notice!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think that they did a good job on this RAVEN zigbee Kit, I am sorry to complain that.

I got two issues so far:
1,I can not debug avrraven_3290p, As both program size of data size are out of memory range.

2,when I start debugging ATmega1284p, the AVRRAVEN board can not communicate with USBSTICK.

3,source codes of IEEE802.15.4 and ZIGBEE are not very clear, right? before I used TI CHIPCON Z-Stack which is much better than the RAVEN.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Vivienne wrote:
1,I can not debug avrraven_3290p, As both program size of data size are out of memory range.

Is this after compiling the code with avr-gcc? The documentation states the code is less optimised than when compiled with IAR and thus won't fit.

They aren't kidding--I've been planning to post about the difference but haven't got to it yet--the bootloader is from memory ~8KB with GCC and 4KB with IAR. (Is this size discrepency "to be expected"?) The "application" is about 107% larger than 32KB for code and 103% larger for RAM.

I've gotten a GCC compiled bootloader to run by ifdef'n out most of the functionality. I also ifdef'd out much of the application code in order to get it to compile to size, but didn't get as far as getting it functional. I did manage to get the application to flash the LED and activate LCD icons--but not display text.

My current plan is to try to compile the full bootloader as the application to see if it works okay.

I've documented some of this but unfortunately my site is currently down.

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They must be doing it wrong. I'd be able to easily test out some GCC switches if they'd supplied proper makefiles, but the AVRStudio dialog isn't flexible enough.

I can see they could have added in -gc-sections, --relax, -mcall-prologues, -finline-limit-20 and a few others (from memory) to get it down in size.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
They must be doing it wrong. I'd be able to easily test out some GCC switches if they'd supplied proper makefiles, but the AVRStudio dialog isn't flexible enough.

I can see they could have added in -gc-sections, --relax, -mcall-prologues, -finline-limit-20 and a few others (from memory) to get it down in size.


I'd appreciate any other suggestions along those lines that I could use in the Makefile AVR Studio lets you export--I'm aiming to be working on a non-Windows platform anyway.

I'll plan to try out the options you've mentioned and see what difference it makes.

Thanks for your reply.

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again...

abcminiuser wrote:
but the AVRStudio dialog isn't flexible enough.

I'm a little confused by this remark--why did you think the flags you suggested couldn't be specified in the dialog?

I've generated Makefiles from the supplied projects and will look at uploading them when my site is on-line again...

Quote:
I can see they could have added in -gc-sections, --relax, -mcall-prologues, -finline-limit-20 and a few others (from memory) to get it down in size.

I tried the flags you suggested and a couple of others I discovered and had small reductions but not significant enough to make the code fit without further work needed.

I've included some details below--I haven't actually tested any of the code generated. (I did wonder if the binaries needed to be stripped.)

Any further suggestions? :-)

--Phil.

======= 3290p_bootloader =======

Program:    9170 bytes (28.0% Full)
(.text + .data + .bootloader)

With -mcall-prologues [Program:    8884 bytes (27.1% Full)]

Unchanged with: --gc-sections -ffunction-sections -fdata-sections  --relax -finline-limit=20  -fmerge-all-constants -funsafe-loop-optimizations

==========================

======= 3290p_application  =======

Program:   35234 bytes (107.5% Full)
(.text + .data + .bootloader)

With -mcall-prologues [Program:   33390 bytes (101.9% Full)]

With above + -finline-limit=20 [Program:   33000 bytes (100.7% Full)]

Unchanged with: --relax --gc-sections -ffunction-sections -fdata-sections -funsafe-loop-optimizations -Wunsafe-loop-optimizations -fmerge-all-constants
==========================
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phil, did you get any further? I'm faced witht he same issue and am now busy stripping functionality out of the 3290p. Haven't yet managed to get it down to size. Looks like it's going to be a bare bones app. It seems almost unbelievable that the IAR compiler is able to compile so much more efficiently - unless of course we're missing a majic GCC switch??

Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

greggallagher wrote:
Phil, did you get any further?

I managed to cut down the bootloader enough eventually to fit (without most of the functionality) but I couldn't get the Alphanumeric LCD code functioning properly.

I then tried using the base bootloader code as the application but the LCD still didn't work so I guess I'm missing something. While I could have tried to see if the radio stuff would work my current thinking is that trying to do it without the display would be an exercise in frustration.

Quote:
Looks like it's going to be a bare bones app.

Yeah, there seems to be a lot of "base" code (LCD, DataFlash, "file system", Radio I/O) that needs to be present before you can get something usefully functional.

Quote:
It seems almost unbelievable that the IAR compiler is able to compile so much more efficiently - unless of course we're missing a majic GCC switch??

It does seem somewhat strange but I don't have enough experience with IAR/GCC differences to know if this is atypical.

All complicated by my web server being down and having dev machine problems. :-(

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

greggallagher wrote:
Phil, did you get any further? I'm faced witht he same issue and am now busy stripping functionality out of the 3290p. Haven't yet managed to get it down to size. Looks like it's going to be a bare bones app. It seems almost unbelievable that the IAR compiler is able to compile so much more efficiently - unless of course we're missing a majic GCC switch??

Greg


hi
I did the same as you. I stripped the speaker and audio and few other small functions. which result that the size is about 73% of the original one. But still if I try to program it, the same fault. stk500dll.
haven't you look inside your hex file?
the hex file has 2 strange rows:
this is end of hex file
:106B280000454D505459004552524F520057414963
:106B38005400444F4E450057524954494E47204D42
:106B48003132383420494D414745001C000000ECE3
:046B58000001000038 row1
:02DFFE0001011F row2
:00000001FF check sum
if I remowe those 2 rows of one of them,I am able to program but with mistakes. do you have any idea why?
did you solved your problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the hex file has 2 strange rows

Strange in what way?

Quote:
if I remowe those 2 rows of one of them,I am able to program but with mistakes. do you have any idea why?

You changed the contents of the HEX file without updating the checksum?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

elmir_24 wrote:

haven't you look inside your hex file?
the hex file has 2 strange rows:
this is end of hex file
:106B280000454D505459004552524F520057414963
:106B38005400444F4E450057524954494E47204D42
:106B48003132383420494D414745001C000000ECE3
:046B58000001000038 row1
:02DFFE0001011F row2
:00000001FF check sum
if I remowe those 2 rows of one of them,I am able to program but with mistakes. do you have any idea why?

I can't quite parse what you were saying, but that does remind me, I did remove the row you have marked as "row 2" because it is outside the address range of the target. I found a setting in the avrstudio file that suggested it's something to do with the firmware version or something? And it's supposed to be "at the end" of memory, I seem to recall.

Deleting the row enabled the hex file to be used.

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

is there anyone who succeed to make the source code fix into 3290p?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems to me that Atmel put the Raven on the market too soon without the developer support (compilable source, drivers, etc.) one would expect. I love the concept, the product, the opportunity to get one for no cost (TNX Atmel!!!) but my Raven is languishing in my bookcase waiting for better support.

I'd be curious how many Raven owners are doing anything productive with their's besides trying make one work?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might have a look at appnote AVR2002:

http://www.atmel.com/dyn/resourc...

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It seems to me that Atmel put the Raven on the market too soon without the developer support (compilable source, drivers, etc.) one would expect.

They have released compilable source which AFAIK runs just fine on the Ravens. It just isn't written for the compiler/toolchain you are using.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

totallyembedded wrote:
It seems to me that Atmel put the Raven on the market too soon without the developer support (compilable source, drivers, etc.) one would expect. I love the concept, the product, the opportunity to get one for no cost (TNX Atmel!!!) but my Raven is languishing in my bookcase waiting for better support.

I'd be curious how many Raven owners are doing anything productive with their's besides trying make one work?

Let me join in with this question.

To which Jörg replied:

dl8dtl wrote:
You might have a look at appnote AVR2002:

http://www.atmel.com/dyn/resourc...

I don't see how that helps?

I want to know if anyone can show how to use the bootloader on the Raven to load a tiny bit of code that will blink an LED on one of the GPIO pins. This should be so simple, yet no one seems to have done even something this simple. I've read the docs and even a lot of the source code and I don't see how to do this other than create a full image of both the 3290P and the 1284 and use the 'Upgrade firmware on node' which is what I think RancidBacon or Follower used which trashed his Raven.

What is going on?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
You might have a look at appnote AVR2002:

http://www.atmel.com/dyn/resourc...


Thank you! Thank you! Thank you! (Now, when did that code appear..? :-) )

I finally have some text reliably displaying on my LCD!

So, no radio interaction yet, but I'm just happy to find something that compiles out-of-the-box with avrgcc and displays my text reliably!

Getting this far wasn't without incident however and you can catch up on the story in the usual place: http://code.rancidbacon.com/LearningAboutAtmelRZRAVEN . There's a gratuitous patch there too.

Side notes: I successfully jumpered the VCC & GND to the 1284p ISP header from the 3290p ISP header. Doing so enabled me to reflash the ATmega1284p which brought my b0rked Raven back to life! Now I'm back to having *two* Ravens to do my bidding!! Ah ha ha! (Well, when they feel like it...)

Also, I uploaded the firmware via the 3290p ISP header--my one additional attempt to use the over-the-air update bizarrely uploaded my original b0rked CRAVE firmware despite referring to the "factory default". Now that I do have ISP ability on both chips maybe I should look into the bootloader functionality again.

I also tried flashing the more recent, more functional firmware and while it worked I couldn't get the audio recording function to, well, function... Not sure why.

Next step I guess is to get the 3290p talking to 1284p radio firmware.

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:

To which Jörg replied:
dl8dtl wrote:
You might have a look at appnote AVR2002:

http://www.atmel.com/dyn/resourc...

I don't see how that helps?


The key piece of text from that document, for me at least, is:

Quote:
The source code is available in the project release folder under the respective folders.
In order to compile the source code provided, WinAVR GCC compiler is a required
plug-in to AVR Studio.

Until that code was released I was unaware of any official Atmel code for the Raven that compiled out-of-the-box with avrgcc and was functional.

Quote:
'Upgrade firmware on node' which is what I think RancidBacon or Follower used which trashed his Raven.

I should point out that the modified firmware I tried to load (unsuccessfully) wasn't compiled from source but was a modified binary (which I didn't check carefully enough). I'm unsure whether an over-the-air update would work compiled from source, but with the most recent firmware update it is apparently possible to store a "known good" firmware in dataflash that can be retrieved (IIRC) via a menu item or shorting two pins. I have not done this successfully however (somehow it stored my b0rked firmware!).

If you're using avrgcc and have a 3290p ISP (or JTAG) header then the code associated with the above document (you'll need to get it from the Raven product page) should help you somewhat.

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well after trolling around to try and find out what to do..... :roll:
I got the basic boards upgraded using the firmware available through AVR2017.
Wireless services (WS) installed and start.
Then soldered the 0.05" JTAG connectors in, USB stick and one AVR Raven board. Once the board connected wirelessly, then through WS forced an
“Update Factory Default data on data flash”.
Requested versions and here is the listing from WS window.
HW 2.0
3290 1.1
1284 1.1
3290 Boot 2.0
1284 Boot 2.0
FD 3290 1.2
FD 1284 1.1
FD 3290 Boot 2.0
FD 1284 Boot 2.0

On the 2nd board AVR Raven tried to update it wirelessly, however it didn't seem to take and had the message "waiting for M1284 Boot Loader"

~Neil :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there enough info in the datasheets to build your own apps?

Cheers, N

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Navigateur wrote:
Is there enough info in the datasheets to build your own apps?

There are the hardware data sheets AVR2017,2002 with CCT diagrams including I saw at one point a good description of the custom RAven LCD mapping to 3290 pins. The processor data sheets are available, and as far as I can see the code for the three processors.
I haven't found any description on how to build the environment - either IAR or GCC - that is what I'm looking at now.
Some one earlier in another forum has put a package together with just the code and it looked like it was GCC build (thankyou)
So far I haven't found the "AVR Wireless services" code

So my objective is to take the RZ Raven and understand how it all went together and what the issues are. Then I've some specific objectives for my own AVR processor application - in particular I would like to have the standard base core functionality stuff like over air upgrading easily sorted out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

neilh wrote:

I haven't found any description on how to build the environment - either IAR or GCC

What does "build the environment" mean? I don't know what it means.

If you mean those register words you can use in C like "PORTA" or "DDRA" then I'm sure you could use the registers' addresses in the datasheet to make your own.

If not, what does it mean?

Thanks, N

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Navigateur wrote:
neilh wrote:

I haven't found any description on how to build the environment - either IAR or GCC

What does "build the environment" mean? I don't know what it means.

So "Build environment" is the tool chain. What does it take in terms of tool chain and commands to be able to produce an error free executable.

BTW ArchRock has a disucssion forum with
http://asdsupport.archrock.com/?...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The factory firmware is available from Atmel in source form, and builds without a hitch right out of the box with IAR- I have been able to do so.

It also can be built with AVR Studio/WinAVR, but the compiler optimizing is not as good, thus the code for the 3290p is too large to fit- I think others have been able to pair it down somewhat to make it fit.

The source is complete in every way- nothing is missing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anybody know if the AVR Wireless Services Code is going to be made available - I'm particularly interesting in the upgrade procedures.

Quote:

It also can be built with AVR Studio/WinAVR
I've found the same for the AVR Studio code and compiled all the code.
The AVR project files are in the gcc directory.
I had a slight problem with the 1284P build. My tools are
AVR Studio 1.4
however the WinAvr\avr\include\avr\iom1248p.h needed a little massage to iron out typos with TCNT1 and UBRR0 bit mapping. I guess I should post it back as an issue.
I was also thinking maybe of adding a description to the RZRaven wiki of the boot architecture which I've been digging into :) (to port to my own ATmega2560 based board)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
They must be doing it wrong. I'd be able to easily test out

From what I've found it appears the linker is not removing unused code.

Doing some tests with the 3290P_bootloader, here is some data for what is not happening.
Any suggestion of switches ?
Size
9272 - 3290P boot loader original size
9144 - replace BLCC_WRITE macro with fn(): application\avrraven\3290P\bootloader\avrraven_3290p_bl.c
8310 remove unused code with switch in application\avrraven\3290p\board_peripherals\df.c
#ifndef AVRRAVEN_3290P_BL_REV_MAJ

So only need to find another 310 bytes and the 3290P bootloader can be gcc-ed.
I'm guessing but the next place it might come from is lcd.c or led.c in application\avrraven\3290p\board_peripherals

I'm using AVR Studio 4.14 which is invoking avr-gcc 4.2.2

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the appropriate switches to remove unused code (why is it in there in the first place?) would be:

-ffunction-sections
-Wl,--gc-sections

Which, coupled with linker relaxations:

-Wl,--relax

And inlining limitations:

-fno-inline-small-functions

Should reduce the code size by a decent amount.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm.. thanks for the input - but nada changed for program size.
I added the options in one-by-one into AVR Studio 4.1, Project->ConfigurationOptions.CustomOptions
CustomCompilationOptions[AllFiles]

Had the following output.
-fno-inline-small-functions cc1 error unrecognised

After adding -Wl,--gc-sections (& -Wl,--relax)the output in the build window said

avr-gcc.exe: --gc-sections: linker input file unused because linking not done
avr-gcc.exe -mmcu=atmega3290p -Wl,-Map=AVRRAVEN_3290p_BOOTLOADER.map -Wl,-section-start=FW_REV_ADR_M3290P_BL=0xfffe hal_m3290_bl.o avrraven_3290p_bl.o bcd.o spi.o adc.o led.o df.o lcd.o self_programming.o     -o AVRRAVEN_3290p_BOOTLOADER.elf

Couldn't find the option descriptions in gcc-4.1.2 manual, but the gcc manuals are for 4.1.2 and 4.3.0. Avr-gcc -dumpversion says 4.2.2
The compiler options that are used are

-mmcu=atmega3290p -Wall -gdwarf-2 -std=gnu99
-Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums  -MD -MP 

So perhaps I'm missing something. Is it possible to tell the linker to reveal itself?
A bit of puzzle
Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got the (standard, unmodified) code down to 6460 bytes with the latest WinAVR applying the above switches.

Quote:

Had the following output.
-fno-inline-small-functions cc1 error unrecognised

You need a newer AVR-GCC - either upgrade or use the alternative:

-finline-limit=20

Which should do more or less the same thing.

Quote:

So perhaps I'm missing something. Is it possible to tell the linker to reveal itself?

You need to add the flags:

Wl,--relax
Wl,--gc-sections

To the "[Linker Options]" section of the project "Custom Options" configuration tab for it to work.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great - what version of the compiler ?
~neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GCC 4.3.0, the one in the latest WinAVR package.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just tried the following flags, and it

...----*~*~*~*worked*~*~*~*------...

Program: 6412 bytes

Note it is slightly different than your suggestion

-Wl,-relax
-Wl,-gc-sections

~Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting... IAR compiles the bootloader down to a hair over 4000 bytes. Wonder how they do that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Probably whole program optimizations, amongst other things. Unfortunatly Atmel haven't supplied proper makefiles (only AVRStudio projects) for the programs, so testing out different flags isn't as easy as it could be. Has anyone converted the programs to use standard makefiles yet?

I now regret giving away my second RZUSBSTICK - I now want to run my MyUSB RNDIS demo on both and see if I can make a simple wireless ethernet adapter between two of the sticks.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any progress? Getting rid of Fahrenheit, 12 hour time, audio playback looping, and audio record (not implemented anyway) takes off 828 bytes. Another 122 bytes by changing bcdtoi to

uint16_t bcdtoi(uint16_t bcd_number)
{
   uint16_t integer;
    
//   integer  = ((bcd_number&0x000F) >>  0) *    1;
//   integer += ((bcd_number&0x00F0) >>  4) *   10;
//   integer += ((bcd_number&0x0F00) >>  8) *  100;
//   integer += ((bcd_number&0xF000) >> 12) * 1000;
    
 	char i;
        for (integer=0,i=12;i>=0;i-=4) 
          integer=10*integer+((bcd_number>>i)&0x0f);
   return integer;
}

But I don't know how to combine with the bootloader for JTAG programming, and have had no success with over-the-air downloading an image (including the Atmel .a90 image, is that supposed to work?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, with all the above changes it's down to Program:29072 bytes Data:1846 bytes without much loss in functionality. Possibly the 4K IAR bootloader could be extracted from the A90 file and pasted into the GCC hex output, but looking at the interrupt vectors it might share some routines with the IAR application. Anyway it didn't work for me when I cut out some audio code to leave room for it.

So I have been trying to get it to run without the bootloader, by turning off the BOOTRST fuse. So far just get a lot of thrashing of the display segments.

The out of range memory address in the hex file is caused by insertion of the revision numbers at the end of application memory, in avrraven_3290p.c

PROGMEM_LOCATION(static uint16_t ATmega3290p_appl_fw_rev, FW_REV_ADR_M3290P_APP) = AVRRAVEN_3290P_APP_REV

where in mmap.h

#define M3290P_BOOT_START_PAGE           M3290P_APP_FLASH_PAGE_COUNT
#define M3290P_BOOT_FLASH_PAGE_COUNT     32UL
#define M3290P_BOOT_FLASH_SIZE           ((uint32_t)M3290P_FLASH_PAGE_SIZE*(uint32_t)M3290P_BOOT_FLASH_PAGE_COUNT)

#define M3290P_APP_START_PAGE            0UL
#define M3290P_APP_FLASH_PAGE_COUNT      ((uint32_t)M3290P_FLASH_PAGE_COUNT-(uint32_t)M3290P_BOOT_FLASH_PAGE_COUNT)
#define M3290P_APP_FLASH_SIZE            ((uint32_t)M3290P_FLASH_PAGE_SIZE*(uint32_t)M3290P_APP_FLASH_PAGE_COUNT)
...
#define FW_REV_ADR_M3290P_APP   (((M3290P_APP_START_PAGE  + M3290P_APP_FLASH_PAGE_COUNT)  * M3290P_FLASH_PAGE_SIZE) - (uint32_t)sizeof(uint16_t))

This seems correct but doesn't matter because it is overridden in the project configuration memory settings -

FW_REV_ADR_M3290P_APP = 0x6fff

Taking that out causes a linker error about overlapping segments, so that's probably why it was added. The correct value is 0x3fff if the application takes all available memory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rjbishop wrote:
The factory firmware is available from Atmel in source form, and builds without a hitch right out of the box with IAR- I have been able to do so.

It's my first time using the raven board. At first, i tried compiling the factory firmware available in Atmel's website using IAR since I've been having problems compiling the code for 3290p using avr gcc. But when I switch to IAR, I still get some errors. This time it's regarding my codes for 1284p. It keeps on telling me that the SPIF0, SPE0, MSTR0, AND SPI2X0 are unidentified identifiers.

I just basically run the file that is loacetd in the IAR folder when I used the IAR software. Is there something I miss out that's why I'm having these kinds of error when compiling the code using IAR?