3

I am trying to develop an ARM development board using ATSAM3U4C with a 96 MHz clock, a few LEDs and a button for external interrupt. Shown below is a little circuit that I have put in place. Using Atmel SAM-ICE 20 pin JTAG connector as the debugger and using Atmel Studio 6.0 for programming. For JTAG connection, pin 3 on 20 pin socket connects to NRST and pin 15 connects to NRSTB.

So far I got the LEDs to blink but I have a few questions:

  1. The debugger does not seem to erase the chip when loading the program. I can run the program once but then to run the program again, I have to use one of the buttons to drive the Erase Pin high (using U5 for now).
  2. I noticed that my 96 MHz crystal oscillator is not actually being used by the ARM processor. Have I wired it incorrectly?

These are the only two issues I am facing right now. I have been using 8-bit microcontrollers and thought this would be a good learning to design my own board and learn to program on it.

enter image description here

David Norman
  • 1,485
  • 2
  • 21
  • 31

1 Answers1

3

I'm not familiar with the ATSAM's, but I know the STM32F4's (as a comparative ARM Cortex-M) wouldn't work with an external 96MHz source - their working range is 4 to 26MHz.

I'd try a slower crystal or oscillator and use the PLL (assuming the ATSAM has one) to increase the system clock to 96MHz.

Re your problems with odd behaviour following an erase/program cycle, maybe try a different toolset. The Coocox IDE (at v.1.7.7) appears to support your MCU (AT91SAM3U4C?), although I'm less sure that it supports the SAM-ICE. If it doesn't then you can buy a CoLinkEx debugger that is definitely supported and should work with almost any Cortex-M for around US$20.

Disclaimer: I have no relationship with Coocox, I just think they have an awesome free product.

I suggest this because I've encountered a situation in the past where if I used vendor A's tools then I had to power cycle between erase/program cycles; but if I used vendor B's tools then I didn't, despite flashing exactly the same binary.

markt
  • 4,956
  • 2
  • 15
  • 13
  • On Page 457 of datasheet under Clock Generator, it says 'A 96 to 192 MHz programmable PLL (input from 8 to 16 MHz), capable of providing the clock MCK to the processor and to the peripherals.' What does this mean exactly? How can a 16 MHz clock help generate 96 MHz? – David Norman Feb 09 '15 at 22:15
  • 1
    The input crystal is up to 16MHz. The internal PLL is able to multiply this frequency up to 192MHz. – Eugene Sh. Feb 09 '15 at 22:28
  • @EugeneSh., Thanks. Why cant 8 bit microcontrollers do this? It will make things a whole lot easier. – David Norman Feb 09 '15 at 23:01
  • @DavidNorman 8-bit MCU's don't do this because they're toys in comparison to any Cortex-M. – markt Feb 09 '15 at 23:19
  • @markt, can you suggest something about the chip erase problem. I have no clue why this is happening. After loading the program once I have to manually pull the Erase pin high to program it again. – David Norman Feb 10 '15 at 06:09
  • @DavidNorman that one I can't help you with; I've never used an ATSAM. The only ARM I've used a lot is the STM32F4, which has no equivalent pin. You issue an Erase command to it via JTAG. – markt Feb 10 '15 at 09:17
  • @markt, JTAG should be erasing the chip by default before uploading the program. But still I erased the .elf file that it uses to program the flash but that still did not work. What works is to drive the ERASE pin high for more than 100mS. – David Norman Feb 10 '15 at 22:20
  • 1
    Your controller may have an option to bypass inner oscillator, at least LPC's have such. That wqy your crystal oscillator could be usable – olltsu Feb 10 '15 at 23:09
  • @DavidNorman updated my answer with a suggestion. – markt Feb 10 '15 at 23:52
  • @markt, ATSAM3u4c is supported by Atmel's SAM-ICE debugger on Atmel Studio 6.0. But I will definitely try out the debugger that you suggested and get back to you. Thanks for your help. – David Norman Feb 11 '15 at 19:16