Reading an ihex with high addresses fails: PIC32 stk500v2 bootloader

[rhae]

Hello,
i have a pic32 where flash resides, at a high address, like 0x1D00'0000 and is of size 0x20'0000. When loading this file avrdude says:

avrdude ihex2b() [fileio.c:346] error: address 0x1d000010 out of range at line 3 of /opt/src/avrdude/app.hex
avrdude do_op() [update.c:485] error: read from file /opt/src/avrdude/app.hex failed

Looking at fileio.c:346 reads like

        nextaddr = ihex.loadofs + baseaddr - fileoffset;
        if (nextaddr + ihex.reclen > (unsigned) bufsize) {
          pmsg_error("address 0x%04x out of range at line %d of %s\n",
            nextaddr+ihex.reclen, lineno, infile);
          return -1;
        }

I guess the description of the part in the avrdude.conf is not ok. My guess is that maybe an offset in avrdude.conf may help.

Do you have any hint for me?

Regards,
Rüdiger

[mcuee]

What is the AVR chip you are using? Take note PIC32 is not supported (either MIPS core or Arm Cortex M core). And take note avr32 is not really supported other than the single chip already supported. No further work will be done for AVR32 as it is kind of obsolete already.

[mcuee]

I think you are on your own here as PIC32 has very different Flash writing mechanism. I do not think STK500v2 is the right protocol to go with. There are already plenty of PIC32 bootloader in the market, including those supported by Microchip. I do not see any of the avrdude development team members are interested in supporting you on this topic.

[stefanrueger]

If it's a bootloader then the chip doesn't matter so much, it's the protocol that counts. (The memory could be a stone slab and the bootloader might instruct a little robot to carve the stone)

[mcuee]

If it's a bootloader then the chip doesn't matter so much, it's the protocol that counts. (The memory could be a stone slab and the bootloader might instruct a little robot to carve the stone)

Interesting to know. I always think bootloaders for different architectures are quite different in the lower level, even though upper level can be quite the same (eg: USB DFU bootloader).

[stefanrueger]

Sure, the bootloaders will be (very) different but they are outside avrdude (and it sounded like @rhae was planning to write one)...

[mcuee]

Ah, that is a good point. I somehow mixed up the host side and the MCU side...

[stefanrueger]

Avrdude's model of AVR memory is that it starts at 0 and has a certain size. There are parts where memory has a notional offset (XMEGAs), and this has been modelled for those parts. Watch out for tests p->prog_modes & PM_PDI in the code (XMEGAs have a for them unique PDI programming interface). I don't know how generalisable the codebase is and whether it's sufficient to declare prog_modes = PM_SPM | PM_PDI for your pic (SPM means bootloader-capability) in addition to setting an offset. The other aspect is that of how Avrdude expects .elf and .hex files to look like. I suspect that Avrdude utilises knowledge how the avr toolchain prepares these (and some of these offsets might be hard-coded, eg, when reading .elf files), so you might need to map your .hex/.elf files first outside Avrdude to different ones removing the offset. As @mcuee said, it's avrdude, not picdude.

I for one wouldn't mind if someone (different from me) took a look at the codebase with a view of making incoming offsets (from .hex/.elf files) and placement offsets in the chip a general proposition that is described in avrdude.conf, and propose a PR provided the code and avrdude.conf remain backward compatible and the ensuing memory model is more general than the current one and encompasses the AVR memory models...

[stefanrueger]

The other thing you can try is to set the size of the memory in ~/.avrduderc to be 0x1d200000, not 0x200000. That will work for reading of the hex file and should work for writing (but note that Avrdude's STK500v2 protocol implementation might only stretch to 3-byte addresses). When reading back the flash file, Avrdude will want to read the full hog of 0x1d200000 as Avrdude does not (yet) allow to uoload/download partial memories (see Issue #1322)

[rhae]

Thanks. I will check your suggestion in the next days...

[rhae]

I think https://github.com/sergev/pic32prog is better suited for my needs.

[mcuee]

Interestingly I found the stk500v2 bootloader for PIC32 here.

• Arduino ATmega2560 stk500v2 (Wiring) bootloader issue #1379 (comment)

[rhae]

Thanks, for the pointer. So when they could use it, the could not have made use of the ihex format but use binary data. I tried to use the ihex format. That is why I had problems. Will try binary eventually.

The code has a comment about avrdude and limit of 64k
https://github.com/chipKIT32/PIC32-avrdude-bootloader/blob/b5234755f65f81b932db8bdd8abc6fefa0b1dbf7/bootloaders/main.c#LL518C6-L520C95
But actually the worked around it.

[stefanrueger]

Will try binary eventually

In some sense ihex, srec etc formats are all converted to binary during file read. One difference is that ihex formats can have holes in them, ie, during upload the programmer might jump from uploading page 42 to uploading page 242. Some bootloaders and/or some (physical) programmer FW cannot cope with non-contiguous upload, some even require upload starts at 0. But that's all outside AVRDUDE...

[rhae]

If I remember correctly, avrdude checks the 64k Limit when reading an ihex file. Since pic32 does start somewhere above 64k it, you can Not use an ihex file. That was the reason I was asking here.

…

---------------------------------------- 11.06.2023 23:37:07 Stefan Rueger ***@***.***>:

> Will try binary eventually In some sense ihex, srec etc formats are all converted to binary during file read. One difference is that ihex formats can have holes in them, ie, during upload the programmer might jump from uploading page 42 to uploading page 242. Some bootloaders and/or some (physical) programmer FW cannot cope with non-contiguous upload, some even require upload starts at 0. But that's all outside AVRDUDE... -- Reply to this email directly or view it on GitHub: #1353 (comment) You are receiving this because you modified the open/close state. Message ID: ***@***.***>

[stefanrueger]

avrdude checks the 64k Limit when reading an ihex file

Not to my knowledge: avrdude implements the Intel Hex format as prescribed and reads/writes arbitrary file sizes. However, if a part has a size of x bytes and one reads a file (doesn't matter which format) then at the most x bytes are set.

[stefanrueger]

@rhae BTW, any part that has PM_aWire set in its avrdude.conf prog_modes parameter observes offset for reading and writing hex files. Doing so might interfere with other programming behaviour but the file I/O should be as I understand you need it for your PIC parts.