Perplexing Xmega Problem - Need Help.

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

 

XMEGA128A3U Processor
AS7 - GCC C Compiler
Atmel ICE Debugger/Programmer

 

I have a perplexing problem that I need some troubleshooting help.

I wrote an application using existing source that has been successfully used in other applications.  The purpose of the application was for some simple eeprom memory testing.  The problem regards a Timer overflow interrupt that *may* work properly depending on how the microcontroller (xmega128A3U) is programmed.

 

This works:
Should the controller be programmed using the Atmel ICE (using PDI with AS7) the application runs as expected.  The Timer ovf interrupt works.  (there is a blinking LED as confirmation).

 

This doesn't work:
When the microcontroller is programmed using my boot loader, the app runs fine with the exception that the timer interrupt is not firing. (No LED blink).  The application is using the USART interrupt and that works as expected.  Memory testing data gets transmitted through the USART, so all of this works as expected.  Only the Timer int is not firing (or it *appears* to not be firing).

 

Here are the steps that I have done at this point to troubleshoot the issue.
1 Program the microcontroller with the PDI interface using the Atmel ICE.  Test.  App runs as expected.
2 Read back the entire FLASH program memory using the Atmel ICE and save the results to a binary file.
3 Program the microcontroller using the Boot loader and repeat the read back to a file.  Test, int not working
4 Test both files for a binary match.  No problems, files matched exactly.
    
5 Modified the application so that the PMIC and TIMER.CNT, etc. registers are reported through the USART.  I was curious if the PMIC interrupt table select bit was reset when jumping to the main application.  I could find nothing out of whack with the interrupt enable bits or PMIC interrupt enable bits.
    
6 Modified the application to use a *different* timer and changed the interrupt vector as needed.  Problem persists.
    
7 Erased just the boot loader memory after programming the microcontroller using the boot loader.  Performed a power up reset and got the same results, the Timer Int will not fire.
    
8 Checked the listing file (LSS) to see if the timer interrupt vector was correct but saw nothing out of the ordinary.
    
I have absolutely no idea WHY I'm seeing this problem.  
Any suggestions from fellow 'freaks' would be appreciated.
Thanks
Jim
    

 

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

What is your bootloader [not] doing that the ICE is doing?  If the flash images are identical, it can't be code, so that leaves the bootloader. 

Greg Muth

Portland, OR, US

Atmel Studio 7 (Version: 7.0.1652) on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

Is the timer used in the bootloader? If so, do you correctly re-initialise it? Perhaps you only configure it using OR rather than starting from scratch.

"This forum helps those that help themselves."

"How have you proved that your chip is running at xxMHz?" - Me

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Does your bootloader reset the XMEGA when loading is complete?  That ought to take care of any lingering peripheral configurations.

 

Greg Muth

Portland, OR, US

Atmel Studio 7 (Version: 7.0.1652) on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

No the timer is not used in the boot loader.  Here is a snippet of what I do when I am ready to

start the main application.

 

I've used this boot loader for some time with no problems (or so I've always thought).

Does anyone see something amiss in this snippet?

 

Thanks for your suggestions.

Jim

 

 

 

// Set up function pointer to RESET vector.
void (*jumptoapp)( void ) = APP_SECTION_START;

//************************************************************************
void StartMainApplication(void)
//************************************************************************
{
    uint8_t temp;
    // jump directly to the application - no wait
    EIND = 0x00;
    temp = PMIC.CTRL & ~PMIC_IVSEL_bm & ~PMIC_LOLVLEN_bm & ~PMIC_MEDLVLEN_bm & ~PMIC_HILVLEN_bm;
    CCP = CCP_IOREG_gc;
    PMIC.CTRL = temp;
    RST_CTRL = 0x01;
    jumptoapp();
}

 

Last Edited: Wed. Dec 20, 2017 - 11:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Both PMIC.CTRL and RST.CTRL have CCP protected bits in them, the Software Reset is not happening.  Try this:

 

    CCP = CCP_IOREG_gc;
    PMIC.CTRL = temp;
    CCP = CCP_IOREG_gc;
    RST_CTRL = 0x01;

 

Greg Muth

Portland, OR, US

Atmel Studio 7 (Version: 7.0.1652) on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

Thanks, Greg -

I'll give that a try tomorrow and report back.

 

Jim

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

Or maybe try _PROTECTED_WRITE ? (same as above but should guarantee timing between CCP and the protected register)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

I haven't had the time to try the boot loader reset issue but it dawned on me that even after a power up reset, the problem persists.

Why would the problem still exist under these conditions?

 

 

As mentioned earlier, I set the FUSE back so that upon a power up reset, pointer boots directly to the application memory and STILL the interrupt issue remains.

 

I'm still going to change the boot loader to resolve the reset issue but I don't see how this affects  my scenario.

I'm running out of ideas.

 

 

 

 

 

 

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

...after a power up reset, the problem persists.

Why would the problem still exist under these conditions?

Good question.  I haven't a clue what the answer might be.   I'm guessing you're right about bootloader reset not making any difference.

 

Where is the target getting its power from?  Is the ICE powering the target when connected? 

 

Greg Muth

Portland, OR, US

Atmel Studio 7 (Version: 7.0.1652) on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

Greg_Muth wrote:
Where is the target getting its power from? Is the ICE powering the target when connected?

 

The ICE does not power the board, the board has a separate power supply.

 

This problem is going to be tough.  I cannot think of anything else to try.  Back to the datasheets to see if there is something I've missed.