Mac OS pic32prog binary is not portable

[John-Titor]

It's not built shared, and it's built i386-only, so even if the user does have a copy of libusb-0.1.4 on their system, it's not going to run (because the library is not normally built fat).

Note that simply replacing the binary with a current pic32prog isn't a quick fix, as a freshly built binary failed to program the Blink example when built for the Olimex Pinguino-OTG board.

[majenkotech]

Did the programming itself fail, or did it program but fail to execute?

I don't have a mac, so have to rely on downloaded copies of programs like pic32prog. If you can provide a newer version that works properly on mac that would be great. I do have a slightly hacked version in the chipKIT repository in UECIDE where I have provided manually edited versions of the usb library (manually edited as in tweaking the search paths inside them) which looked like it was going to begin to work. You might try that out.

[John-Titor]

The supplied pic32prog doesn't run (it's not built fat, and there is no 32-bit slice in libusb-0.1.4 as installed by Homebrew since nobody runs on 32-bit machines anymore).

If I replace it with a pic32prog that I built myself, it fails to program - you can probably reproduce this on Windows/Linux with a freshly-built pic32prog, since it seems to be a fundamental disagreement between the linker script and the tool - pic32prog insists that (at least part) of the space to be programmed isn't writable.

[majenkotech]

I have just uploaded a new version of the core that has the pic32prog and libs that I crafted for the chipKIT core in it. Can you give it a try and see if it a) runs, and b) programs?

[John-Titor]

Will do - if you have a pointer to a forum or some general advice on untangling linker maps and other low-level stuff that'd help write more detailed bugs, too.

Sent from my iPhone

On May 24, 2014, at 2:22 PM, Matt Jenkins notifications@github.com wrote:

I have just uploaded a new version of the core that has the pic32prog and libs that I crafted for the chipKIT core in it. Can you give it a try and see if it a) runs, and b) programs?

— Reply to this email directly or view it on GitHub.

[John-Titor]

You've supplied a 32-bit-only pic32prog, though it now seems to run OK.

Programming now fails in the same fashion I mentioned before:

/Users/john-titor/Library/uecide/cores/chipKIT/tools/macosx/pic32prog -p Blink.hex 
Programmer for Microchip PIC32 microcontrollers, Version 1.
    Copyright: (C) 2011-2012 Serge Vakulenko
      Adapter: HID Bootloader
 Program area: 1d005000-1d03ffff
    Processor: Bootloader
 Flash memory: 236 kbytes
         Data: 5652 bytes
        Erase: done
address 1d000000 out of program area
...

It's linking with chipKIT-application-32MX440F256.ld, which seems to specify stuff (exceptions, by the looks of it) at 0x9d000000, whilst the Olimex-Pinguino board has the 12K HID bootloader at that address.

This is where I come a bit unstuck; nobody seems to have any consensus about how to lay out linker scripts for these devices, so they are all a complete mess, and none of the bootloaders seem to document how executables should be arranged to work correctly.

[majenkotech]

So it looks like it's going to need a special linker script just for the pinguino's bootloader that shifts the kseg0_program_mem from 0x9D001000 to 0x9D005000 to account for the bootloader. I'm not sure where it would expect the exception memory to be... Maybe the exception memory is at 0x9D005000 and the kseg0_program_mem should be at 0x9D006000? I guess it all depends on what the user application load address is in the bootloader...

[majenkotech]

I have crafted an olimex bootloader specific board for the Pinguino. I found a linker script buried in their IDE and have taken the right values from it to craft what looks like it might be a good linker script for that board. Give it a go and see if it works.