Good Atmel ARM support sites

[MacGyverS2000]

Looking for a quality forum that supports the Atmel ARM series (the AT91RM9200 specifically). I've come across a few "posers", but the posters tend to be students or hobbyists that can't even figure out how to blink LEDs, or sites that have a ton of questions but no answers (similar to TI's official forum for their DSPs).

My latest attempt was at at91.com, but again, lots of questions with few answers. Anyone out there working with ARMs and have some high-end support forums in their bookmarks?


Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

Sorry man, No... Same as your last question I just have marginal exposure to ARMs too.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[Madcow]

Sorry,here too.
We've had bad support from Atmel.
I heard they got rid of most of their FAE's.
We couldn't even get support from the factory.
We used the alzheimers chip ,it would forget its
programming after 6 months.
Did I tell you, it would forget its
programming after 6 months.

If you find a good one let me know.

 

[richs]

Let us know if you find one Dan.

Right now, I'm on the LPC2000 group with the NXP (Philips)
ARM 7 SOC group.

Lot's of newbies, but since I'm a newbie with that chip, it's o.k. for me. There seems to be a couple of folks who know on the board. Most have gotten through the blinky LED stuff and it seems that it's more about interrupts or "funnies" with the peripherals. Some on development toochains, most of these too are not the get it up and running but how do I configure it to do.....

So, maybe it's one step above the newbie level? You might be hard pressed to find a "free" group with enough experience to really bounce questions off of.

Group is:

http://tech.groups.yahoo.com/group/lpc2000/

membership required. No spam but a lot of "How do I?"

Might be worth a post? See if there is any valid response then bail from the group......

Cheers,

Rich S.

 

[MacGyverS2000]

I'm kind of beyond the blinking LED phase with this chip, but I have to admit it has been one of the most difficult architectures I've ever worked with (and I'm including parallel processors, DSPs, and many other micros). I suppose the difficulty comes from never having to worry about every little detail of the system in the past, including boot code, etc. PICS, for example, are easy-peasy to create boot code for as there are no peripherals.

With the current system, I'm actually forced to deal with things like external RAM access timing, reset sequences, etc. I've muddled my way through it with an occasional dose of help from my boss (who is intimately familiar with these chips), but I can't keep relying on him to solve my problems. I'm a wiz at writing highly optimized assembly code for DSPs, parallel processors, and the like, but never having taken a proper computer architecture or algorithms class during my school days is starting to show the cracks in my armor. All it takes is a single non-obvious problem and I'm stuck for days/weeks until I either get lucky or someone comes to my rescue. Hell, not being able to figure out that RAM timing was an issue caused a two week delay in the boot code many months back, and that was only resolved with the correct suggestion from my boss. Not a good situation for job security.

At the moment, I'm working on a bootloader to allow for field upgrades. The main app works by itself on the system just fine and has been running in the field for several months. The bootloader does its job loading the main app code into flash (verified by looking at it byte for byte).

If I run both together in debug mode using JTAG, the bootloader works like a charm, allows me to download new code, erase flash, etc. and the main app starts without issue. Without the debugger, the bootloader still works, but the main app refuses to start. My boss has suggested the only difference between the two setups is the Startup.s file that gets the clocks running, sets up memory timing, etc. I have removed all of the similar stuff from the main app's .s file (memory timing doesn't need to be set up twice, clocks are already running, etc.), but that still hasn't resolved the problem.

VERY frustrating!


Dan - Owner

http://www.Hi-TecDesigns.com

 

[richs]

Hi Dan-

In light of your current problem. Just a suggestion.
Can you run the main app from external RAM? If so, then
when the main app fails to run, you can be monitoring the
address lines and data from a logic analyzer and get an idea
of where the chip thinks it is by what it's accessing on
the external RAM?

This is an old technique and although it is far from an ICE, it does allow it to run "real time" although the timing for the external RAM might be a problem.

The other "quicky" that comes to mind is try slowing down the processor. With *MY* ARM, and I think that it's common with most of them. They have a PLL that can be changed to adjust the clock frequency. That would be a second try at it.

I too have had "interesting" stuff with the ARM and sorely miss having JTAG right now. I'm seriously considering it in the very near future. Since it comes out of the enginnering budget (read as *MY* back pocket), I'm trying to lowball it. I am thinking along the lines of a generic JTAG interface with one chunk of hardware to program the ARM, FPGA's etc. Something a little higher up the food chain than the "wiggler" types.

I also spent a couple of weeks trying to get the damned VIC controller working correctly. I insturmented the code with an LCD display, poked around printing out variables, and "you are here" messages, started over from scratch a couple of times and even went on the internet for help.

Finally found it when I was trying to clear a different variable to reset the interrupt hardware. I must have looke d at that line of code a couple of dozen times at least before it filtered into my meager brain. That was last week for me. I'm still kicking myself on that one.

Oh, one final suggestion. Have the bootloader load a dummy application to see if and where the dummy application will load and start properly. It doesn't have to be much, maybe just hack out a bunch of the main app stuff and leave in the hardware initialization, and have the main app reduced to "blinking the LED". Then add code back in 'till it dies. You know the old trick of #ifdef NEVER/#endif 'ing large blocks of code out.

Take comfort in the fact that there is a fair likelyhood that your hardware is at least up and running! Could you imagine the frustration if you couldn't get the main app up and running AND you didn't trust the hardware?

Rereading your post yet again, it certianly "smells" like a timing problem. On the Philips chip (from the documentation) running the JTAG is not necessarily running the device real time. YMMV on this depending upon the JTAG software running.

Best of luck. One final note. It's funny. After the two week stint with the interrupts I was saying to myself "I'm kinda glad that I'm doing this on my own time. I would hate to have a client (or a boss) have these little slips in their schedule." The learning curve hasn't been all that steep, but it has been a learning curve.

Cheers,

Rich S.