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

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 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): 

  • 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.:

 

  • 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)

  • 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 :-(