SAM Datasheets - No 'soft erase' procedure.

Using Arduino Microcontrollers
1

Hi all,

Having just been doing some work to get Atmel Studio working with my Due, and having to erase the chip manually to get it ready for programming - I've had a thought. The Arduino product page says the following about the SAM3X8E native USB port.

Opening and closing the Native port at 1200bps triggers a 'soft erase' procedure: the flash memory is erased and the board is restarted with the bootloader. If the MCU crashed for some reason it is likely that the soft erase procedure won't work as this procedure happens entirely in software on the SAM3X.

However, I'm searching through the datasheet trying to find information about this 1200bps soft erase procedure. I cannot seem to find any reference, is there an 'official' name I should be looking for?

I've searched terms such as the following, with no luck

  • 1200
  • 1200bps
  • soft erase
  • erase

Any ideas what to look for, I'd like just like to have a little read up about this.

Cheers!

2

It's probably implemented in the Arduino bootloader.

3

johnwasser:
It's probably implemented in the Arduino bootloader.

...but the bootloader on the SAM isn't a piece of Arduino software, it's the target bootloader for the SAM-BA ISP tool which comes in the chip from the factory and cannot be changed, which BOSSAC targets when called by the Arduino IDE - and it can't be the bootloader on the 16U2, as the Native USB port isn't connected to the 16U2.

I'm thinking perhaps the reason I cannot find it, is there's perhaps a fuse (although they're not called fuses on the SAM, they're ...NVMs or something?) which when certain bits are selected allows one to scale down a number, and 1200 is one of the options.

4

No, it's not the bootloader.. But it's a part of your sketch.. When you compile your sketch there is a bunch of files/libraries getting compiled together with the sketch..

The 1200bps open and close routine is a part of the arduino USB code.. If you want to see it for yourself open the following file:

C:\arduino-1.5.2\hardware\arduino\sam\cores\arduino\USB\CDC.cpp

...

You'll find it somewhere between line 128 and 142... Here is a part from the code:

	if (CDC_SET_CONTROL_LINE_STATE == r)
		{
			_usbLineInfo.lineState = setup.wValueL;
			// auto-reset into the bootloader is triggered when the port, already
			// open at 1200 bps, is closed.
			if (1200 == _usbLineInfo.dwDTERate)
			{
				// We check DTR state to determine if host port is open (bit 0 of lineState).
				if ((_usbLineInfo.lineState & 0x01) == 0)
					initiateReset(250);
				else
					cancelReset();
			}
			return true;
		}

//Basel

5

I see - I need to have a read of all that code today.

So... the 1200 bps part isn't actually a specification of the SAM chip itself - but, a sketch uploaded by the Arduino IDE that is now on the chip, detects the opening and closing of the USB port at 1200bps, and triggers and erase and pulls the SAM-BA bootloader out of ROM ready to be used.

I didn't realise the SAM could be reset, erased and prepared from software - I thought it was a hardware thing, or a 'hard-wired' sequenced such as 1200bps open and close from the factory.

I'll try this this evening, but my guess is then - if I upload some code from Atmel Studio using ASF code and BOSSAC, and then try and program the board using the Arduino IDE - i'll probably have to press the erase and reset button myself?

Page 327 (331 specifically) of the full SAM3X8E datasheet has the details of entering the programming mode...

Just a thought baselsw - regarding our issues with SAM-BA. When one erases the SAM chip with the erase button, and hit's reset, I don't think this actually pulls the SAM-BA out of ROM ready to be used by SAM-BA, I think it just erases the flash ready to be written to by something like BOSSAC. Actually, erasing the chip and resetting it must use the SAM-BA software out of the ROM, as it deals with serial communications.

The datasheet is a little unclear on all of this - what do you think?

EDIT - Here we go, straight from the datasheet -

"Setting GPNVM Bit 1 selects the boot from the Flash, clearing it selects the boot from the ROM.
Asserting ERASE clears GPNVM Bit 1 and thus selects the boot from the ROM by default."

So, erasing the chip boots the chip from ROM, where SAM-BA is contained. So I guess the way the programming port works, it clears the GPNVM bit, and resets the chip - so that it boots from ROM, and then uses BOSSAC to erase the flash prior to uploading new code.

So no, that dosen't explain our issues with the SAM-BA GUI...

6

Yes, we had a similar discussion about the bootloader somewhere in this forum (or maybe another forum?).. The 1200bps trigger won't erase the flash.. it just simply send the sam chip to the bootloader... The bootloader makes the soft erase and programs your sketch..

Hard erasing and reseting the chip will send it to the bootloader (ROM, as you found in the datasheet.. No, this is not the problem that's preventing us from communicating with SAM-BA..

May I ask why you need to use sam-ba?

7

May I ask why you need to use sam-ba?

I don't - per se, as BOSSAC works fine, and I can include BOSSAC in an application if I like to be able to program my devices. (Speaking of BOSSAC by the way, who makes it - and where can I find documentation etc?)

It simply frustrates me, that I cannot, or we cannot, get the official Atmel tool to even connect to the devices...

8

jtw11:
I don't - per se, as BOSSAC works fine, and I can include BOSSAC in an application if I like to be able to program my devices. (Speaking of BOSSAC by the way, who makes it - and where can I find documentation etc?)

It simply frustrates me, that I cannot, or we cannot, get the official Atmel tool to even connect to the devices...

Well, you're not using an official Atmel board ;)... Here is a link to the official website for bossa (bossac).. BOSSA | shumatech.com

Edit: Quote from the bossa website:

SAM-BA ships with support for all of Atmel's evaluation kits but does not provide generic configurations for other boards. It is a complex task with little documentation to modify SAM-BA to support custom boards. Sometimes, one can get away with using one of the evaluation kit configurations if it is similar to a custom board but other times not since custom external devices could cause a conflict.

//Basel

9

Ah, I had found BOSSA - and thought the name was very similar but it's not all that clear if BOSSA 'own' BOSSAC.

Funnily enough however, I cannot get the BOSSA GUI to work, even though BOSSAC works fine... :slight_smile:

10

soft reset with 1200 BAUD does not seem to delete the sketch, how does bossac keep the ARM looping in the sam-ba bootloader?