• AVR Freaks

Hot!IPE v5.25 Problems flashing ATmega3208

Author
ajosev5
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/04/29 11:42:30
  • Location: 0
  • Status: offline
2019/10/23 13:49:54 (permalink)
0

IPE v5.25 Problems flashing ATmega3208

Platform: Windows+Linux
Programmer: Atmel-ICE
Interface: UPDI
MCU: AVR ATmega3208
 
Hello,
 
I have been having some frustrations getting MPLAB X IPE working as expected to flash .hex files to my MCU.  I have two images - one bootloader and one application.  Developing in Atmel Studio, I have had no problems flashing one and then the other, using the option to disable erase before flash. 
 
The problems I've run into are:
1) No option under Settings to toggle "Erase All Before Program".  IPE User's Guide says this should be an option under the Settings drop-down.  I do not have this, in either Windows or Linux versions.  So I already can't flash one hex image then the other, without erasing the last one.  If I check "Allow Erase All Before Program", in the Production Settings, I still get a greyed out toggle under the Settings drop down.  Since Atmel Studio programming tools do allow this, I have to assume this is a limitation in the IPE.
 
2) To try to work around the above, I combined the two hex files with hexmate and attempted to flash this.  But no success in IPE.  On inspection after reading back the device flash, the second (applicaton) image does not get fully flashed.  IPE stops flashing the hex after address 6FFF, followed with 0x150 or so bytes of 0's, then leaves the rest of the memory as 0xFF.  What?!  Atmel Studio programming tool flashes the same combined hex correctly.  So I can only narrow this one down to the software as well, or just to my incorrect understanding of the myriad of settings in IPE.
 
Memory settings: Tried both allow tool to select, and manually select ranges
Program Memory Range: 0-7FFF (entire flash memory range of my device)
Preserve Program memory (unchecked)
 
The IPE output is strange too - when I have manual range 0-7FFF selected, it tells me it is programming 0x0 - 0x3FFF.  With automatic range, it says 0x0 - 0x38BF.  I don't understand how the memory settings could result in this - it doesn't correspond with what it is actually doing, either.  So I'm at a total loss here.  
 
For anyone in the know - are there some options I could be missing or have set incorrectly?  I know support for AVRs is a relatively recent addition.  Is it just still in beta status and basically broken?
 
Thanks!
#1

5 Replies Related Threads

    HowardH
    Super Member
    • Total Posts : 799
    • Reward points : 0
    • Joined: 2006/01/20 10:21:24
    • Location: Microchip Technology - Chandler, AZ
    • Status: offline
    Re: IPE v5.25 Problems flashing ATmega3208 2019/11/12 14:50:06 (permalink)
    0
    Hi ajosev5,
     
    We went through your scenarios and found some things that may help.
    #1 - The "Erase All Before Program” is disabled by default, but to enable it, you can do a “Read” operation first in IPE and the option would be applied.  You can uncheck the drop down and then program.  This will erase (or not) the memory image before programming.  The other option is to use the “Preserve program memory” option.This would also not erase everything and preserve the needed.
    I agree that this is not intuitive and will create a request to add better usability to this.
     
    #2 and #3, was not able to duplicate this.  But hopefully if #1 works for you, you will not need to use hexmate to combine the images as you were doing.  We also didn't see any issues with programming the full range either.  
     
    We were using MPLAB X IDE v5.30 for our analysis.  
     
    Let us know if you have any problems in performing a READ first.  
     
    Thanks,
     
    Howard
    #2
    ajosev5
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2019/04/29 11:42:30
    • Location: 0
    • Status: offline
    Re: IPE v5.25 Problems flashing ATmega3208 2019/11/14 08:36:33 (permalink)
    0
    HowardH
    Hi ajosev5,
     
    We went through your scenarios and found some things that may help.
    #1 - The "Erase All Before Program” is disabled by default, but to enable it, you can do a “Read” operation first in IPE and the option would be applied.  You can uncheck the drop down and then program.  This will erase (or not) the memory image before programming.  The other option is to use the “Preserve program memory” option.This would also not erase everything and preserve the needed.
    I agree that this is not intuitive and will create a request to add better usability to this.
     
    #2 and #3, was not able to duplicate this.  But hopefully if #1 works for you, you will not need to use hexmate to combine the images as you were doing.  We also didn't see any issues with programming the full range either.  
     
    We were using MPLAB X IDE v5.30 for our analysis.  
     
    Let us know if you have any problems in performing a READ first.  
     
    Thanks,
     
    Howard




    Howard, thanks for chiming in and attempting to duplicate.  
     
    I went the route of using "Preserve Program Memory Range(s)" when programming the application section after bootloader.  I'm not sure how I may have missed this option before, or if perhaps it was greyed out before I performed a read.  I did a read before each attempt at programming.  It appears to me that IPE takes memory ranges as 16-bit words, so my 32K memory device prog memory range is 0-3FFF words.  So after the bootloader was flashed successfully, I checked "Preserve" and entered the memory range that my bootloader is in.  Then I manually entered the range to program to be the range of the application section.
     
    The result: with "Preserve Program Memory Range(s)" checked, and my application hex loaded, it appears IPE did not do any programming - in fact, I could watch my bootloader code continually looping (debug output) as I attempted to program, so it appears IPE did not even reset the chip to start.  If I unchecked Preserve, it would actually program but the bootloader section would be, possibly as expected, erased.  Here is a screenshot link of the programming window showing logs and memory settings - one the successful bootloader programming, and then the unsuccessful attempt at programming the application afterwards.
     
    https://imgur.com/a/yEGO2RY
     
    Also, as before, the full application does not get flashed - it gets cut off somewhere around 2/3 of the way through as I described in the original post.
     
    Here are my bootloader and app memory sections...
    Bootloader:  0-17FF (bytes) = 0-0BFF (words)
    Application: 1800-7FFF (bytes) = 0C00-3FFF (words)
     
    So I'm still scratching my head here... thanks again for helping look into this.
    #3
    HowardH
    Super Member
    • Total Posts : 799
    • Reward points : 0
    • Joined: 2006/01/20 10:21:24
    • Location: Microchip Technology - Chandler, AZ
    • Status: offline
    Re: IPE v5.25 Problems flashing ATmega3208 2019/11/21 16:30:34 (permalink)
    0
    Thanks ajosev5.  Let me look into it further.
     
    Regards,
     
    Howard
    #4
    ajosev5
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2019/04/29 11:42:30
    • Location: 0
    • Status: offline
    Re: IPE v5.25 Problems flashing ATmega3208 2019/11/22 07:30:14 (permalink)
    0
    HowardH
    Thanks ajosev5.  Let me look into it further.
     
    Regards,
     
    Howard




    Howard,
     
    Just had a Microchip FAE stop by yesterday as they were intrigued by the main problem, which was not writing the entirety of the hex to the MCU.  We spent a couple hours working through it and found that IPE is puking if you load a hex with an address offset - in my case, an application that sits after a bootloader section (as described in my posts beforE) and starts at memory 0x1800.  The problem does not occur at the MCU flashing stage, but rather at the stage where IPE loads the hex into RAM (you can look at it in the program memory view).  It puts 0's in the addresses from 0 up to the offset, and does not load the whole contents of the hex in - it stops at a seemingly random point.
     
    The issue was alleviated if we artificially inserted 0xFF's into memory ranges 0-0x17FF of that hex.  We did this by erasing and reading the MCU memory so we could just copy paste that section in.  
     
    I wonder if you would experience the same problem if you tried something similar.  This occurred on versions 5.25 and 5.30.  But in any case, Microchip is now aware of the bug and hopefully they will work a fix in soon.
     
    Thanks,
    Tony
    #5
    HowardH
    Super Member
    • Total Posts : 799
    • Reward points : 0
    • Joined: 2006/01/20 10:21:24
    • Location: Microchip Technology - Chandler, AZ
    • Status: offline
    Re: IPE v5.25 Problems flashing ATmega3208 2019/11/22 10:07:04 (permalink)
    0
    Hi Tony,
     
    Yes, the FAE has alerted us to it and we see the same as well, although one thing that I see happening is if the hex file starts at the offset, the area prior to that is 0xFFFF, rather than 0x0000 in flash, as you had mentioned.
    Regardless, we'll have the developers review this and investigate.  
     
    Thanks for bringing it to our attention.  I will keep our FAE in the loop.
     
    Regards,
     
    Howard
    #6
    Jump to:
    © 2019 APG vNext Commercial Version 4.5