AVR2054 problems with xmega256a6u

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the bootloader code from avr2054 compiled and loaded.  I have a simple flash LED program that I am trying to upload to the chip using the bootloader.  I am using the PC java client to upload the blink program.  The blink program is in the s record format. 

 

I have the bootloader compiled to use USTART F0.

 

WHen I try the upload I see the handshack_req from the PC client.  Next I see the handshake_conf from the xmega.  Next the client sends the first s record what appears to get formatted correctly.  But the xmega never sends an ACK or a NACK.  The byte counts appear to be right on...

 

Any cluse from someone who may have gotten this working?

 

 

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

A little update on what I am seeing...

 

In the switch statement of the function srecParser() the code seems to just stop.  

 

In the code snippet below I put in a statement to turn on an LED.  sbi(6)  Where I have it in the code it will turn on the LED after the handshake is exchanged and I've send the S0 line of my srecord data.  BUT, the switch statement never executes.  I tested this by moving the sbi statement after the switch statement, as well as trying it inside each case, and the default.

 

Might the processor may be getting an interrupt that is somehow taking the program flow elsewhere? 

 

THis is weird...

 

 

 

static bool srecParser(void)
{
  uint8_t addressLength;
  uint8_t checksum = 0;
  
  // start of packet is transmitted as ascii code.
  // the others are transmitted as hex code.
  // search begin of packet
  srecWaitForType(&dataBuffer.recordType);
  
sbi(6);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Turn on LED

 
  switch (dataBuffer.recordType)
  {
    case S0: // the address field is 2 bytes
    case S1:
    case S5:
    case S9:
        addressLength = 2;		 
      break;
    case S2: // the address field is 3 bytes
    case S8:
        addressLength = 3;
      break;
    case S3: // the address field is 4 bytes
    case S7:
        addressLength = 4;
      break;
    default: // unsupported type
      return false;
   }


  // get packet length

 

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

atmegger wrote:

Might the processor may be getting an interrupt that is somehow taking the program flow elsewhere? 

Sure.  You must have an ISR to handle each interrupt that is enabled.  You also need to switch the interrupt vectors from the application memory to the bootloader memory.

 

I don't know anything about AVR2054 and I guess nobody else does either.

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

LOL!

 

I ended up taking the path of least resistance and switched to xBoot, which is working great.

 

steve17 wrote:

 

atmegger wrote:

 

Might the processor may be getting an interrupt that is somehow taking the program flow elsewhere? 

 

Sure.  You must have an ISR to handle each interrupt that is enabled.  You also need to switch the interrupt vectors from the application memory to the bootloader memory.

 

 

I don't know anything about AVR2054 and I guess nobody else does either.

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

Hi there

 

I have had the same problem with this boot loader and an older AES bootloader (http://www.atmel.com/images/doc2...). The older bootloader was programmed in May 2014 in the Atmel Studio 6 version 6.0 (not the latest studio 6.2), installed on units and has worked without a problem in the field. (If I compile this old working project with Studio 6.2. 1563 - Service Pack 2, the bootloader no longer works)

 

I had to update this old bootloader and used the latest version of Studio 6.2. The bootloader no longer works, and resets the micro as it enters a switch statement. The cause of this is unknown.

 

I then attempted to use this new AVR2054 bootloader for the USART 0 ATMEGA1281, and began to have similar problems. The switch statement in the static bool srecParser(void) funciton (in srecParser.c) causes the micro to reset? I then replaced this switch statement with an if/else statement and the bootloader succeeds past this point, however the application is not being written to the application space? I am closer but not there yet! What would cause this? I fear that there is a fundermental problem here.

 

The application code (which was also previously written under an earlier version of AVR studio), also exhibited some strange behaviour. The code seemed to be running slowly. After investigating this problem it was found that the % (modulus) operator was causing the system to slow down. This was previously working code, just rebuilt with the new IDE. This was resolved by removing these moduli operators.

 

I am not sure where in the tool chain the problem is coming from, the compiler? Please help!

 

Regards,

Derek

 

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

The compiler will put a "jump table" or something like that in flash when the switch has many cases.  These things then have to be read from flash.  When the flash is in high memory where the addresses require more than 16 bits, a slightly different technique needs to be used to access the flash.  Sometimes that is not done right.

 

Another possible problem reading flash is that the NVM controller must have the correct command (no operation) to read flash.  Generally it is assumed that this command will be there.  The bootloader will change the NVM command to read or write various memory.  It should restore the "no operation" command afterwards and probably does.  But some of us screw up. 

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

Double post due to "technical difficulties".

Last Edited: Fri. Mar 20, 2015 - 11:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Triple post due to "technical difficulties".

Last Edited: Fri. Mar 20, 2015 - 11:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the explanation for the switch statement. I presumed the fact that the micro ATMEGA1281 has >64kB of memory might be causing the issues. That said is it the compiler that is not generating the correct machine code from the C code? If so, what has changed with the compiler?

 

The problem now is that the new application code is not writing to the application area. The bootloader is executing the SPM  command yet the application is not wirintg to memory. I have confirmed this by reading the entire flash, the bootloader is in the correct place by the application space is all 0xFF.

 

What could be causing this? I am using the virtually unchanged AVR2054 code!

 

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

Compilers change.  Actually all good software, software that people use, is always changing.  It may be that the compiler you used in the past didn't use a jump table.

 

I have no idea why your bootloader without the switch writes nothing to application flash.

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

Thanks, I shall have to keep digging!

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

If I was thrashing around trying to figure it out, I might try to see if the bootloader could do anything right, like read flash or eeprom or fuses.

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

I spent a long time messing around with AVR2054 and never could get it to function properly.  I switched paths and ended up going with xboot and it works perfect.  I think that may be a much better route than beating your head against the wall, unless you want to fix 2054 as an academic exercise. 

 

RE: compilers and environments.   I come from the network/sysadmin  world philosophically. "Only upgrade if there is a problem or clear advantage".  Otherwise every time you upgrade from a stable environment you should do a complete regression test.  Embedded development is about stability, and has never been about features.  The M$ pc/java/Iworld mentality has shifted otherwise rational engineers into believing that they have to always be at the cutting edge of development tools/environments to function.  This is NOT true at all.  It is more important to understand that you are looking at reality than the image of what may be reality.  No matter how productive a GUI makes you feel, at the end of the day it is still about the compiled code that gets spit out the end.  If the tool chain is hiding a bug you've lost every speed advantage you've gained.