AVR911 xml files for xmega

Go To Last Post
62 posts / 0 new

Pages

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

davidgrm wrote:
You seem to have missed above where I said that I got it working on the one that I built in A6 without using the makefile, that is why I thought it would be interesting to see if you use my makfile settings which I posted above to compile it in your invironment and then let me test the hex file on my board.

I saw it, but those settings won't cause any issues either way. If you got the bootloader to work using AS6, it must be an issue with your compiler. Are you using nmake in powershell or vs shell?

A better test would be for you to download and install cygwin + winavr and atmel toolchain 3.4.2. If you get it to work using that combination of software, then the problem is likely whatever you're currently doing outside of AS6. If you have a few minutes tonight, we can do that together.

Also, upload your AS6 project that works please. That will be very helpful.

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

I do appreciate your persistance and help. Thanks a lot

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

davidgrm wrote:
I do appreciate your persistance and help. Thanks a lot

No problem. I really hope we figure out a solution. Thanks for your contributions. I think you've helped fix a few errors and inconsistencies.

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

Quote:

Are you using nmake in powershell or vs shell?

I use winxp ->Run->cmd I then used make that came with the version of GCC that comes with A6

C:\Program Files\Atmel\Atmel Studio 6.0\make\make.exe
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.

The thing is that I am happy compiling without make. I do my debugging in A6 and also programming of devices. I am just trying to get it to work with make so that other people dont have to go through the same thing. That is why I thought that if you build the hex file on a system that you know works for other varients of AVR then it will be a good test to see if it it works in the 64a3U

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

davidgrm wrote:
Quote:

Are you using nmake in powershell or vs shell?

I use winxp ->Run->cmd I then used make that came with the version of GCC that comes with A6

C:\Program Files\Atmel\Atmel Studio 6.0\make\make.exe
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.

The thing is that I am happy compiling without make. I do my debugging in A6 and also programming of devices. I am just trying to get it to work with make so that other people dont have to go through the same thing. That is why I thought that if you build the hex file on a system that you know works for other varients of AVR then it will be a good test to see if it it works in the 64a3U

I see. I'll do that when I get home and we'll see what happens. I'm fairly confident that the problem isn't with the bootloader. It seems to be related to the way you're building/compiling, but I don't know for sure.

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

A very strange thing happened. I rebooted my PC and then made the change to the code for when avrdude ends programming that you posted above. After that my code also did not work anymore. After doing some debugging I have finaly figured out what the actual problem is. It has to do with the way I operated my board.
How I operated my board.. For testing I deleted my program so the memory was just full of 0xff = NOP. Now when reset, if I did not hold the button down then the code would enter the boot loader and exit , then run through all the nops of missing code and back into the bootloader until I pressed the button. But what this does is it locks the Flash and prevents further programing until a reset happens. This bit of code which is the else part of the if statement which checks if the button is pressed:

    else
    {
		SP_WaitForSPM();
		SP_LockSPM();
		EIND = 0x00;
		funcptr(); // Jump to Reset vector 0x0000 in Application Section.
    }

notice the

SP_LockSPM();

statement. I had seen this but assumed that the SPM was unlocked by some code in the sp_driver. I just read this in the data sheet:

Quote:
Bit 0 – SPMLOCK: SPM Locked
This bit can be written to prevent all further self-programming. The bit is cleared at reset, and cannot be cleared from
software.

I am not sure why my code worked multiple times earlier because I was operating it in the same way. In fact when I compared the code built with make and the code built without make multiple times I did each the same way. I have re-tested the eeprom issue and that does not seem to have an effect although it did earlier. :roll:

This is an easy mistake to make if the chip is blank because you can enter the bootloader at any time as I did. We should change the code so that if the spm lock is enabled it will force a reset. This will happen so quickly that you will still be pressing the button after restart and will enter the bootloader correctly

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

Add this to reset if SPM locked:

		if(NVM.CTRLB & NVM_SPMLOCK_bm)
		{
			CCP_RST();
		}	

It will be after the if statement that checks if the pin is enabled to enter the bootloader and just above:

	
		/* Initialization */
		ADDR_T address = 0;
		unsigned int temp_int = 0;
		unsigned char val = 0;
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
A very strange thing happened. I rebooted my PC and then made the change to the code for when avrdude ends programming that you posted above. After that my code also did not work anymore. After doing some debugging I have finaly figured out what the actual problem is. It has to do with the way I operated my board.
How I operated my board.. For testing I deleted my program so the memory was just full of 0xff = NOP. Now when reset, if I did not hold the button down then the code would enter the boot loader and exit , then run through all the nops of missing code and back into the bootloader until I pressed the button. But what this does is it locks the Flash and prevents further programing until a reset happens. This bit of code which is the else part of the if statement which checks if the button is pressed:

    else
    {
		SP_WaitForSPM();
		SP_LockSPM();
		EIND = 0x00;
		funcptr(); // Jump to Reset vector 0x0000 in Application Section.
    }

notice the

SP_LockSPM();

statement. I had seen this but assumed that the SPM was unlocked by some code in the sp_driver. I just read this in the data sheet:

Quote:
Bit 0 – SPMLOCK: SPM Locked
This bit can be written to prevent all further self-programming. The bit is cleared at reset, and cannot be cleared from
software.

I am not sure why my code worked multiple times earlier because I was operating it in the same way. In fact when I compared the code built with make and the code built without make multiple times I did each the same way. I have re-tested the eeprom issue and that does not seem to have an effect although it did earlier. :roll:

This is an easy mistake to make if the chip is blank because you can enter the bootloader at any time as I did. We should change the code so that if the spm lock is enabled it will force a reset. This will happen so quickly that you will still be pressing the button after restart and will enter the bootloader correctly

Hmm.. I changed that function several times in the past, but I can't remember why I settled on what's currently committed. When the bootloader exits, this is the code that runs:

else if(val=='E') {
    // Clear the transmit complete flag
    Uart(MY_UART).STATUS = (1 << USART_TXCIF_bp);
    sendchar('\r');
    while (!(Uart(MY_UART).STATUS & (1 << USART_TXCIF_bp)));
    SP_WaitForSPM();
    CCP_RST();
}

I wrote CCP_RST(), which is an assembly function that does a literal reset of the board to make sure peripherals aren't initialized accidentally or unintentionally. That requires the bootloader entry condition to be cleared because the bootloader will enter again very quickly and then you'll have to force an exit condition with a programmer. With that said, I could change the last few lines to execute CCP_RST() and that will unlock the SPM bit. I could also add a check for the SPM bit at the beginning of the loop that did check the bootloader entry pin and then successfully entered the main bootloader loop.

I'm glad you got it working.

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

Add this to reset if SPM locked:

		if(NVM.CTRLB & NVM_SPMLOCK_bm)
		{
			CCP_RST();
		}	

It will be after the if statement that checks if the pin is enabled to enter the bootloader and just above:

	
		/* Initialization */
		ADDR_T address = 0;
		unsigned int temp_int = 0;

You do want to make sure that it is locked after exit. That was the problem of the other bootloader I used. I dont think it was locked so sometimes on start up your main app would get a page deleted.

Just another thing regarding this problem. When I was testing, if it did not program the chip I did not reset, I just pressed the button and it went back into the bootloader. I did not know it was locked lol

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

I use this to reset

	CCPWrite( &RST.CTRL, RST_SWRST_bm );//do a reset

But you do need the CCPWrite code which is also used for other things such as clock configuring

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

davidgrm wrote:
I use this to reset
	CCPWrite( &RST.CTRL, RST_SWRST_bm );//do a reset

But you do need the CCPWrite code which is also used for other things such as clock configuring

CCP_RST does the same thing after writing the unlock code.

I updated the code. The first commit is the lock bit fix. The second commit is for readability. The main .c file is much cleaner now and I also added defines for the commands.

Pages