MPLAB and PICKit4/SNAP/ipecmd fails to handle non-continuous code?

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4162 View posts
Location: SF Bay area
#1
Posted by westfw: Thu. Sep 5, 2019 - 06:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(MPLAB question in this section, now?)

Can someone check my sanity?

I'm working on a bootloader for Xtiny and Mega0, and I wanted to have a "default" application included, that would cause "reasonable behavior" if only the bootloader had been programmed.  So I did something like:

 

int main() {

    VPORTA.DIR = 0xFF;
    VPORTA.OUT = 0x55;
}

void  __attribute__((section( "postapp")))
        __attribute__((naked)) __attribute__((used)) app();
void app() 
{
    VPORTA.DIR = 0xFF;
    VPORTA.OUT = 0xFF;
}

Where the "postapp" part is moved at link time beyond the bootloader segment,  using:

avr-gcc -mmcu=attiny412 -nostdlib -nostartfiles -Wl,--section-start=postapp=0x200 main.o -o main.elf

 

This works OK, at least using avr-gcc.  I get a .o file, .elf file, and .hex file, all with the sections where I expect them to be.

But the MPLAB tools (mplab itself, or the ipecmd CLI tool) will only actually program the first section (using PICKit4 and/or SNAP.)

The tiny is of particular interest, but I have the same problem if I change the target to a ATmega4809.

 

I've attached a zipped MPLAB project, and a much simpler CLI/Makefile that I think reproduces the problem.

I am using a Mac; I haven't checked whether that matters...

 

Attachment(s): 

Package icon bug_sections_mplab.zip
Package icon bug_sections_cli.zip

Tags:

Tools, Atmel Studio (AVR-related)
Top
N.Winterbottom
N.Winterbottom's picture
Level: Resident
Joined: Tue. Oct 1, 2002
Posts: 991 View posts
Location: Redbourn, Herts, UK
Posted by N.Winterbottom: Thu. Sep 5, 2019 - 08:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


By discontinuous do you mean "has gaps in the hexfile" ?

 

Because almost every PIC hexfile conatins the Configuration Word (functionally like AVR fuses) at the very top of Program Flash so ordinarily has a gap.

 

This screenshot is for low end PIC24 but examine the MPLABX IPE screen here for your processor and in particular the memory areas to program.:

 

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97624 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Sep 5, 2019 - 08:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aside: Why __attribute__((naked)) in that? Your app() will have no RET and because there's no while(1) it will do the two VPORT writes then just head off through memory executing the 0xFFFFs.

 

As the app() has no CRT the least you can do is add the while(1)

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4162 View posts
Location: SF Bay area
Posted by westfw: Thu. Sep 5, 2019 - 09:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, gaps.  I don't think "special" memory areas (config, fuses, whatever) counts, because they're handled differently.  (the FUSES in the bootloader code program fine, for instance.)

 

I started with "let MPLAB pick the memory to program", but went to an explicit range when it picked wrong.  But it still doesn't program the second section.

 

I essentially want the actual bootloader "application section" to clear reset causes and loop around to run the bootloader again, so that a freshly programmed chip will loop through the bootloader.  With the latest optiboot logic that tries to preserve reset-cause, that wouldn't (might not?) happen:

Power on, no-wait check, skip bootloader, start application, fall off the end, back into bootloader, repeat :-(

 

 

Top