It looks to me like the Ethernet Shield is NOT 3.3V compatible, I suggest don't connect it to Due.

There does seem to be an implementation of Ethernet library for Due, whether it works or not is a question. I can't see how it would have been tested with a Due/Ethernet shield, unless there is an unannounced 3.3V version in the works.

ETA: clarify wording

Hello guys.
Long time reader first time poster.

Im designing my own board for another purpose using the same ATSAM3X chip, and after reading this thread I am still a little confused as to how to setup External ram as a continuation of the internal ram - presumable this is possible.

What I mean by this, assuming that all the control, data and address lines are connected correctly to an external chip, how does the MCU know to point the stack to this external memory once all of the internal 48Kb internal ram is used ? is it automatic after setting some SMC control bit in some register?

If this is not possible, then it requires some memory management in code which is quite annoying. Any help would be appreciated.

Fair question. The external memory appears to the MCU as a block of memory at an address depending on its Chip Select line. (These pins are labelled NCS0-NCS7 on the SAM3X). Typically you would connect CSx to the CS pin on your memory device. The lowest 24 bits of a memory address are decoded by the external memory device, the upper 8 bits are decoded in the memory controller. The locations of the memory sections are shown in Figure 8-1 of the SAM3X User Manual. For example, CS0 maps to 0x60000000.

The second question is how to map the application code to memory regions. This can be done very simply by direct access and setup from the application code, but this method is less flexible. You can allocate dynamic variables at runtime just by setting their address to a hardcoded value correspodning to the external memory. If you want to get automatic placement of variables, then you would need to use the linker.

By changing the linker file, you can specify the additional memory region, and what should go into it. At runtime, RAM variables will be zeroed or initialised with data copied from Flash as necessary. This is part of the Standard C initialisation procedure. With GCC toolchain you may need to edit a startup file to include the additional memory regions.

Note that you will need to edit the startup code to setup the memory controller before letting the code does its memory copying/zeroing. If you put the stack into external memory, you must make sure your startup code does not use it before it is setup! It is probably best to set a temporary stack in internal RAM for the startup code, and then change stack after the external memory is setup. It is simpler though to keep stack in internal memory, and use the external memory for other stuff.

The third question is how to get the application to use the extended memory. This can be done in the linker file, using combination of "pragma section" and the linker file, or explicitly in the application, depending on taste.

If this all seems quite complicated, then you are probably right. It needs good knowledge of the MCU and the toolchain to set the right things at the right point. Once setup, it becomes fairly seamless, but get one tiny thing wrong and it falls over in a heap.

To keep it simple, I would probably use direct setup from the application, and use the external memory as a pool of dynamic buffers for bulk data.

If you can interface SRAM to SAM3X, then you should be able to interface a NOR Flash and run code direct from Flash (will be slower needing wait states). Other permutations are possible, for example you could read from serial/NAND Flash and copy to RAM etc. You would have to write a small amount of bootstrap code since this type of thing is not directly supported by the toolchain.

I'm not sure how flexible the memory controller on the SAM3X is, but with ARM7 and ARM9 projects I have worked on most RAM and Flash was external, the chips only had a few K of RAM on board.

Just for interest, here is a board I am working on to interface Due to a 3D printer controller (RAMPS)

http://reprap.org/wiki/File:RAMPS-RIB-Back.jpg
http://reprap.org/wiki/File:RAMPS-RIB-Assembly.jpg

It is application specific, I am using TXS0108 to adapt some signals, with some gate drivers for MOSFETS.

I had trouble finding connectors with the same height, but they seem to connect ok.

Source files on github https://github.com/bobc/bobc_hardware/tree/master/RAMPS-FD

Those messages indicate that the J-link adapter is just not seeing any sensible data on the JTAG pins. Assuming that your hardware is working correctly, then the JTAG pins may not be mapped to JTAG depending on what software is loaded in the SAM3X, a whole chip ERASE should clear that. Another thing that could cause this is a misconnected header. It is worth noting here that the orientation of the JTAG header on the Taiji is 180° opposite to the Due, which could lead to confusion. There is a small dot on the board indicating pin 1, easy to miss.

It's not like it gets hot.. Just a bit warm, something I never experienced with a AVR (maybe because of the freq. that the processor is working with)..

Exactly that, the logic gates consume power when they change state, if you are running at a higher frequency then the chip consumes more power (all other things being equal). 28 degrees is well within normal. Nice work with the temperature chart btw 

Given the fact that you have many more gates in an ARM compared to an AVR and are clocking them 4 times faster, it is pretty good that it does not get hotter. Running at lower voltage (3.3V vs 5V) helps a lot with that, as well as the CPU design. By comparison, the old 486 from Intel needed at least a heatsink to run at similar clock rates, if not active cooling.

The baudrate does not affect the speed of USB transfer if you are just doing PC to MCU transfers, and are not driving an actual UART.

USB transfer rate is affected by two things, polling interval and packet size. Polling interval in USB High speed is a multiple of 125us, and the max packet size is 1024 bytes for CDC class (interrupt transfers).

That seems to be consistent with your results. To maximise throughput, you need to at least buffer up to 1024 bytes to get the most from each transfer. In the worst case, if you send 1 byte in a transfer, you have to wait at least 125us before being polled again, and that latency kills the transfer rate. Protocols that do short request/response transactions should be avoided, you need a protocol with a streaming mode.

To avoid latency further, use larger buffer sizes, and I mean really large, like 32Kb, or for more efficient use of RAM use a double buffer scheme, so you fill one while the other is transferring, then switch over.

Of course, maximising throughput with large buffers is OK for bulk transfer like data logging, but creates a latency problem if you do small transfers with a request/response protocol, but you need to avoid those anyway.

I am wondering if your chip has not gone through the erase sequence, which is required to get into the bootloader. The ERASE pin needs to be high during reset and held high for 220ms.

I found with SAM7S my chip could get into a "bricked" state, and doing the erase procedure would recover it, sometimes took more than one go to do it.

I don't know where the 9-pin format came from, is it created by Segger? It does not seem to be an ARM standard.

Personally I prefer to use a header with a polarised housing. The key pin does the same job, but I am not going around cutting pins off headers... Seems a bad idea to introduce an incompatible standard, for a marginal improvement.

I think you would need at least a different variable to record previousMillis for red and blue LEDs.

This response, and really the question that prompted it is where I'm lacking on the knowledge front mostly. Just taken a look at the Jlink unit (http://www.segger.com/j-link-edu.html), so - are devices like that programmers, or just debuggers for the JTAG interface? (JTAG is something I've never worked with before either)

If yes, do they program over an SPI interface the same as the AVR ISP does with the 8bit AVRs?

JTAG is a general purpose test/debug interface, it includes a serial interface like SPI. It allows "back door" access to any CPU register or address bus, and also to an on-chip debugger. This allows breakpoints, watchpoints to be set, and allows interruption of the CPU execution so that external access can be made. So you can do a lot of things, including programming internal and external flash, debugging.

Saying that, I can't seem to find the 4E chips for sale by any of the big vendors in the UK. Or anywhere outside of the UK for that matter...

Seems like the Atmel Cortex M4 parts are still fairly new.

Why SAM4E?

A number of reasons;

- integral FPU
- largest SRAM & flash of all the ARM MCUs
- highest number of timers

The Cortex M4 parts are pretty beefy, and price not much greater than Cortex M3, so I see the attraction.

I've just taken a look in the ASF documentation - whilst the SAM4E-EK board is not supported, the SAM4E devices themselves are, and the typical features present on the eval boards such as LCD displays, QTouch etc are not features i'm remotely interested in using. The target application for my personal dev board is automated control applications, without the need for screens etc.

http://asf.atmel.com/docs/latest/

Ah, my mistake, I was looking at older version of ASF. The latest ASF has SAM4E stuff in. One thing Atmel are pretty good on, is documentation, examples, reference designs, framework code, etc, and they make it all easy to get hold of. So if I was starting with a new design, Atmel is a good choice from that point of view. I actually prefer NXP or ST ARM chips over Atmel, but Atmel ARM chips are good enough.

Perhaps as you mention - working with the SAM3X in my own board first would be a better option, as a revision down the road to switch to the SAM4E would be less of a jump, but then again - my board design currently uses a AVR 2560, so that board revision from AVR to SAM3X would be enormous as is, so it seems to make logical sense to jump straight to the intended device.

I wouldn't necessarily recommend SAM3X as first option, I was thinking more of something like SAM3S. I am a believer in incremental change, or at least starting with something that is known to work. I would generally start with an off the shelf eval board, and find an IDE with a project ready for the board (setting up all the project options is tricky enough). Then I go to my own hardware, a different toolchain, and create projects from scratch.

If you can find the right eval board, extra cost incurred may be only a few $. Official manufacturer eval kits tend to be stupidly expensive, with a few notable exceptions (e.g ST Discovery boards) but there are people like Olimex who create low cost options. If you need to run a sample project built for IAR, Keil etc, there are usually free/limited "lite" versions you can use, but for Atmel you probably don't need to look further than Atmel Studio.

This switch isn't planned for probably 9 months, I'm just looking to get thoughts into it - but ultimately how to upload to the SAM devices from Atmel Studio, like I say - I've only ever worked 8-bit with the AVR ISP MkII programmer. (or of course the Arduino IDE)

Atmel Studio + Segger Jlink EDU version is a great combo for bare metal programming. The ASF provides a pretty useful peripheral library, but not as easy to use as Arduino libraries.

Maybe what I said sounded a little too negative, Cortex parts are relatively easy to use, though still a step up from AVR. There has never been a better set of freely available tools and resources to help designers. So go for it, just beware there may be a fairly steep learning curve. Some people enjoy the challenge, and if motivated it's not a problem.

Interesting, seems to be a bug in the GCC code, reent.h should have "#ifdef DEBUG"?

I'm slightly puzzled as to why this problem does not occur more often, it seems like it should happen whenever DEBUG is not defined.

Why SAM4E?

If you've never used a 32 bit before, designing a new board with a SAM4E may be a little ambitious. Getting SAM4E to work with Arduino IDE is not a trivial exercise. I think you would be better off with Atmel Studio. Normally I would suggest using the corresponding eval board as a reference, but there appears to be no support for SAM4E-EK in the ASF yet, and setting up for a custom board is not a trivial exercise either.

I would strongly recommend starting with something more widely supported with documented samples to start with. For a first project, get familiar with the toolchain, the IDE, the driver libraries and the chip capabilities first, then you will be in a much better position to branch out with a custom design.

I've not found any cheap JTAG adapters to be very reliable, and usually take a good deal of effort to work at all. For some combinations of OS, software, drivers and hardware they can work well, but it seems pretty hit and miss.

The professional level JTAG adapters are usually pretty reliable, some are better than others, but to get that quality for a specialist product inevitably costs money. It depends on how you value your time, but I do a lot of embedded programming so I prefer spending the money for the ease of use.

With Atmel, we are in luck, because there is an Atmel version of the Segger J-Link, which are pretty good and widely supported, and the Atmel version is considerably cheaper than the full Segger J-Link. I believe they work with OpenOCD and Atmel studio. There is an "educational" version of Segger J-Link as well which is cheaper than the full version.

For the 20 to 10 pin adapter, these can be got from ebay for a few $, Olimex also do one for €5.